Introduction

There is no single fastest serializer for every .NET workload because performance depends on payload shape, allocation budget, compatibility requirements, and whether the format must be human-readable. The practical answer is to pick the format that matches the constraint first, then benchmark with representative objects instead of chasing generic speed claims.

Start by choosing the format category

The first decision is not the library. It is the wire format. Human-readable formats such as JSON are convenient for APIs and logs, while binary formats are usually smaller and faster for internal traffic or persistence.

For most application code, the tradeoff looks like this:

• 'System.Text.Json is the default built-in choice for JSON.'
• MessagePack or protobuf-based libraries are usually better when compact binary speed matters.
• 'BinaryFormatter should not be used because it is obsolete and unsafe.'

That framing matters more than micro-optimizing method calls.

Use System.Text.Json for modern JSON workloads

If you need JSON, System.Text.Json is generally the best default in current .NET code because it is built into the platform, fast enough for most services, and avoids an extra dependency.

1using System;
2using System.Text.Json;
3
4public record User(int Id, string Name);
5
6public class Program
7{
8    public static void Main()
9    {
10        var user = new User(1, "Ava");
11        string json = JsonSerializer.Serialize(user);
12        User? copy = JsonSerializer.Deserialize<User>(json);
13
14        Console.WriteLine(json);
15        Console.WriteLine(copy?.Name);
16    }
17}

For web APIs and config-like payloads, this is usually the right balance of speed, safety, and maintainability.

Use binary serializers for speed-critical internal data

If both ends of the pipeline are under your control and readability is not required, a binary serializer usually wins on throughput and payload size. MessagePack-style serializers are especially common for cache entries, internal RPC, or very high-volume messaging.

1using MessagePack;
2using System;
3
4[MessagePackObject]
5public class User
6{
7    [Key(0)] public int Id { get; set; }
8    [Key(1)] public string Name { get; set; } = string.Empty;
9}
10
11public class Program
12{
13    public static void Main()
14    {
15        var user = new User { Id = 1, Name = "Ava" };
16        byte[] bytes = MessagePackSerializer.Serialize(user);
17        User copy = MessagePackSerializer.Deserialize<User>(bytes);
18
19        Console.WriteLine(bytes.Length);
20        Console.WriteLine(copy.Name);
21    }
22}

The exact fastest library varies by model and benchmark, which is why testing your real object graph matters.

Serialization speed depends on object shape

Flat DTOs with primitive fields serialize much faster than graphs with many nested objects, dictionaries, polymorphic members, or reflection-heavy converters. If performance matters, simplify the transferred shape before switching libraries. A smaller, flatter contract often produces a bigger gain than moving from one decent serializer to another.

This is one reason API contracts and caching models are often separated from domain entities.

Benchmark both serialization and deserialization

Developers often measure only serialization throughput, but deserialization can be the real bottleneck in services that read far more than they write. Use BenchmarkDotNet with representative payloads.

1using BenchmarkDotNet.Attributes;
2using BenchmarkDotNet.Running;
3using System.Text.Json;
4
5public record User(int Id, string Name);
6
7[MemoryDiagnoser]
8public class SerializerBenchmarks
9{
10    private readonly User _user = new(1, "Ava");
11    private readonly string _json = JsonSerializer.Serialize(new User(1, "Ava"));
12
13    [Benchmark]
14    public string Serialize() => JsonSerializer.Serialize(_user);
15
16    [Benchmark]
17    public User? Deserialize() => JsonSerializer.Deserialize<User>(_json);
18}
19
20public class Program
21{
22    public static void Main() => BenchmarkRunner.Run<SerializerBenchmarks>();
23}

Without this kind of measurement, it is easy to choose based on anecdotes instead of workload.

Avoid unsafe legacy options

BinaryFormatter used to appear in performance discussions, but it should not be used in modern .NET applications. Security and compatibility risks outweigh any convenience. For most teams, the real choice is between built-in JSON and a binary serializer designed for performance.

Common Pitfalls

• Asking for the fastest serializer before deciding whether the format must be JSON, binary, or human-readable.
• Using BinaryFormatter even though it is obsolete and unsafe.
• Benchmarking toy objects that do not resemble the real production payloads.
• Measuring only serialization speed while ignoring deserialization cost and memory allocation.
• Switching libraries before simplifying an overly complex object graph.

Summary

• Choose the format category before choosing the library.
• Use System.Text.Json as the default for modern JSON in .NET.
• Use a binary serializer when internal throughput and payload size matter more than readability.
• Benchmark with real payloads using tools such as BenchmarkDotNet.
• Avoid legacy serializers that are unsafe or no longer recommended.