Introduction

.NET 4 does have built-in JSON support, but it is not the same modern API surface that developers know from System.Text.Json in newer runtimes. In classic .NET Framework 4, the built-in choices are mainly JavaScriptSerializer and DataContractJsonSerializer, while many projects still prefer Json.NET for convenience and flexibility.

JavaScriptSerializer

One built-in option is JavaScriptSerializer from System.Web.Script.Serialization. It can serialize and deserialize common object graphs without adding a third-party package.

1using System;
2using System.Web.Script.Serialization;
3
4public class Person
5{
6    public string Name { get; set; }
7    public int Age { get; set; }
8}
9
10class Program
11{
12    static void Main()
13    {
14        var serializer = new JavaScriptSerializer();
15
16        string json = serializer.Serialize(new Person { Name = "Ada", Age = 36 });
17        Console.WriteLine(json);
18
19        Person person = serializer.Deserialize<Person>(json);
20        Console.WriteLine(person.Name);
21    }
22}

This works well for straightforward scenarios, especially in older ASP.NET applications that already reference the relevant assemblies.

DataContractJsonSerializer

Another built-in option is DataContractJsonSerializer from System.Runtime.Serialization.Json. This one fits best when your types are already modeled with data contract attributes or you want explicit serialization contracts.

1using System;
2using System.IO;
3using System.Runtime.Serialization;
4using System.Runtime.Serialization.Json;
5using System.Text;
6
7[DataContract]
8public class Person
9{
10    [DataMember]
11    public string Name { get; set; }
12
13    [DataMember]
14    public int Age { get; set; }
15}
16
17class Program
18{
19    static void Main()
20    {
21        var serializer = new DataContractJsonSerializer(typeof(Person));
22        var person = new Person { Name = "Ada", Age = 36 };
23
24        using var stream = new MemoryStream();
25        serializer.WriteObject(stream, person);
26        string json = Encoding.UTF8.GetString(stream.ToArray());
27        Console.WriteLine(json);
28    }
29}

It is a built-in serializer, but it is more contract-oriented than many developers expect.

Why Many Teams Still Use Json.NET

Even though .NET 4 includes built-in JSON serializers, Json.NET became the default choice in many projects because it offers:

• more flexible customization,
• more familiar attribute support,
• stronger handling of messy real-world JSON,
• a smoother developer experience.

So the accurate answer is not "no built-in support." It is "yes, but many people still choose a third-party library because the built-in APIs are more limited or less ergonomic."

That nuance matters when you are maintaining an old codebase. You may not need to add a dependency immediately if the built-in serializer already covers the shape of JSON you are dealing with.

Which Built-In Option to Choose

As a rule of thumb:

• use JavaScriptSerializer for simple legacy scenarios,
• use DataContractJsonSerializer when data contracts fit your model,
• use Json.NET if you need richer features and can accept the dependency.

That decision often depends more on the surrounding codebase than on raw serializer capability.

In other words, the existence of built-in support answers the platform question, but the library choice is still an application design decision.

That is the practical answer most teams need.

It also avoids unnecessary package churn.

Common Pitfalls

• Assuming .NET 4 has no built-in JSON support at all.
• Expecting System.Text.Json, which belongs to newer runtime generations.
• Choosing DataContractJsonSerializer without understanding its contract-based style.
• Pulling in a third-party library before checking whether the built-in APIs are already sufficient.
• Mixing serializer libraries in one application without a clear reason.

Summary

• .NET 4 does include built-in JSON serializers.
• The main built-in choices are JavaScriptSerializer and DataContractJsonSerializer.
• These are different from modern System.Text.Json.
• Many teams still prefer Json.NET because it is more flexible and convenient.
• The best choice depends on your app's age, dependencies, and JSON complexity.