Introduction

ViewData and ViewBag both let an ASP.NET MVC controller pass small pieces of data to a view during the current request. The main difference is that ViewData is a dictionary, while ViewBag is a dynamic wrapper on top of that same underlying storage.

ViewData Is a Dictionary

ViewData stores values by string key:

1public ActionResult Index()
2{
3    ViewData["Greeting"] = "Hello, world!";
4    return View();
5}

In the view, you read it back by key and usually cast it:

1@{
2    var message = (string)ViewData["Greeting"];
3}
4
5<p>@message</p>

Because the values are stored as objects, you lose compile-time type safety and can make mistakes with key names or casts.

ViewBag Is a Dynamic Wrapper

ViewBag provides property-style syntax:

1public ActionResult Index()
2{
3    ViewBag.Greeting = "Hello, world!";
4    return View();
5}

In the view:

<p>@ViewBag.Greeting</p>

This is more concise, but it is not fundamentally a separate storage mechanism. Under the hood, ViewBag writes into ViewData.

That means these are effectively connected:

ViewData["Greeting"] = "Hello";
// ViewBag.Greeting now sees the same value

Choose Based on Readability, Not Power

Since ViewBag and ViewData ultimately point to the same request-scoped data concept, the choice is usually about style:

• 'ViewData is explicit and dictionary-based'
• 'ViewBag is shorter and more readable for small ad hoc values'

Neither one is a good substitute for a real strongly typed view model when the view needs meaningful structured data.

For example, a proper view model is often better:

1public class HomeViewModel
2{
3    public string Greeting { get; set; }
4    public int NotificationCount { get; set; }
5}

That gives compile-time checking and clearer intent than a growing pile of string keys or dynamic properties.

This is why many teams use ViewBag or ViewData only for very small, incidental values such as a page title or a temporary message, while using typed models for the main content of the view.

That convention keeps controllers and views easier to refactor later. Dynamic and dictionary-based values are convenient in the moment, but they do not age as well as typed contracts when the view grows more complex.

For teams maintaining older MVC applications, that is often the practical compromise: allow ViewBag or ViewData for small page metadata, but move business-relevant data into proper typed models as the view evolves over time and grows steadily in complexity overall later naturally too everywhere.

Common Pitfalls

The biggest mistake is treating ViewBag as if it were strongly typed. It is convenient, but misspelled property names are only caught at runtime.

Another common issue is overusing either ViewBag or ViewData for large or important data structures. Once a view depends on several fields, a dedicated view model is usually the cleaner design.

People also assume the two mechanisms are isolated from each other. They are not. Since ViewBag is backed by ViewData, changing one can affect what the other sees.

Finally, remember that both are request-scoped. They are meant for passing data from controller to view for one response, not for persistence across requests.

Summary

• 'ViewData is a dictionary keyed by strings.'
• 'ViewBag is a dynamic wrapper around ViewData.'
• 'ViewBag is more concise, but both share the same underlying request-scoped data.'
• Neither is strongly typed, so both are weaker than a dedicated view model.
• Use a view model when the view needs more than a couple of small values.