Is there a serializable generic Key/Value pair class in .NET?
Object-Oriented Design practice on Codemia
Turn requirements into classes, and defend the design, on the problems that come up in OOD rounds.
Introduction
KeyValuePair<TKey, TValue> is the built-in generic key/value struct in .NET, and it is serializable with most modern serializers (System.Text.Json, Newtonsoft.Json, XmlSerializer). However, it is a read-only struct — its Key and Value properties have no setters, which causes issues with some older serializers that require settable properties. For those cases, you can create a simple custom class or use Tuple<T1, T2>, Dictionary<TKey, TValue>, or anonymous types.
KeyValuePair with System.Text.Json
System.Text.Json handles KeyValuePair natively since .NET Core 3.0.
KeyValuePair with Newtonsoft.Json
Newtonsoft.Json serializes KeyValuePair by default.
KeyValuePair with XmlSerializer
XmlSerializer requires settable properties. KeyValuePair<TKey, TValue> has read-only properties, so direct XML serialization fails:
Custom Serializable Key/Value Class
Create a class with settable properties for XML or legacy serializer compatibility:
Serializing Dictionary Entries
A Dictionary<TKey, TValue> serializes as a JSON object, which is often more natural:
For a list of key/value pairs (allowing duplicate keys):
Tuple as an Alternative
Tuples work for serialization but use Item1/Item2 naming (for Tuple<>) unless you use named ValueTuples.
Record Type (C# 9+)
Records provide built-in equality, immutability, and serialization support:
Records are the modern, clean approach for immutable key/value types.
DataContract Serialization
For WCF or DataContract-based serialization:
Common Pitfalls
- XmlSerializer requiring settable properties:
KeyValuePair<TKey, TValue>has read-onlyKeyandValueproperties.XmlSerializerneeds setters for deserialization. Create a custom class with settable properties or use a different serializer. - Parameterless constructor required: Many serializers (XmlSerializer, some JSON deserializers) require a parameterless constructor.
KeyValuePair<TKey, TValue>has one (it is a struct), but custom classes must explicitly define one. - Dictionary keys must be strings for JSON object serialization:
System.Text.JsonserializesDictionary<string, T>as a JSON object. Non-string keys (e.g.,Dictionary<int, string>) are serialized differently or may fail. UseJsonConverterfor custom key types. - Duplicate keys in Dictionary:
Dictionary<TKey, TValue>does not allow duplicate keys. If you need duplicate keys, useList<KeyValuePair<TKey, TValue>>instead. - ValueTuple field names lost at runtime: Named ValueTuple fields (
(string Name, int Age)) are erased by the compiler. Serializers may produceItem1/Item2instead ofName/Age. Use records or classes for reliable named serialization.
Summary
KeyValuePair<TKey, TValue>works with System.Text.Json and Newtonsoft.Json out of the box- For XmlSerializer, create a custom class with settable properties and a parameterless constructor
- Use
Dictionary<string, TValue>when keys are unique and string-typed for natural JSON serialization - Use
List<KeyValuePair<TKey, TValue>>when duplicate keys are needed - C# records (
record KeyValue<TKey, TValue>(TKey Key, TValue Value)) are the cleanest modern approach - Always test serialization round-trips (serialize then deserialize) to verify data integrity
Related reading
- Is there a simple, elegant way to define singletons?
- Is there an alternative to bastard injection? AKA poor man's injection via default constructor
- IServiceCollection does not contain a defintion for AddHttpClient
- IUnityContainer.ResolveT throws error claiming it cannot be used with type parameters
- Is there a split list method in c?
- Is there a string math evaluator in .NET?
- Java Constructor Inheritance
- Java generics T vs Object

OOD Fundamentals
Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
Object-Oriented Design practice on Codemia
Turn requirements into classes, and defend the design, on the problems that come up in OOD rounds.