Introduction

Yes, .NET has a JSON equivalent to XmlIgnore. For modern System.Text.Json, the usual attribute is [JsonIgnore], and for Newtonsoft.Json the attribute has the same name. The important detail is knowing which serializer you are using and whether you are ignoring a property, a field, or only certain values.

Core Sections

Ignore a Property With System.Text.Json

If your project uses System.Text.Json, add [JsonIgnore] from System.Text.Json.Serialization.

1using System.Text.Json;
2using System.Text.Json.Serialization;
3
4public class UserProfile
5{
6    public string Name { get; set; } = "";
7
8    [JsonIgnore]
9    public string InternalToken { get; set; } = "";
10}
11
12var user = new UserProfile
13{
14    Name = "Mark",
15    InternalToken = "secret-value"
16};
17
18string json = JsonSerializer.Serialize(user);
19Console.WriteLine(json);

The output includes Name but not InternalToken. That is the closest direct parallel to [XmlIgnore].

Conditional Ignore Behavior

System.Text.Json also supports conditional behavior through JsonIgnoreCondition.

1using System.Text.Json.Serialization;
2
3public class ApiResponse
4{
5    public string Status { get; set; } = "ok";
6
7    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
8    public string? DebugMessage { get; set; }
9}

That tells the serializer to omit the property only when it is null. Similar options exist for default values and read-only members, depending on your scenario.

This is useful when you do not want to ignore a member permanently, only under certain output conditions.

Newtonsoft.Json Uses a Similar Attribute

If the codebase uses Newtonsoft.Json, the pattern looks very similar:

1using Newtonsoft.Json;
2
3public class UserProfile
4{
5    public string Name { get; set; } = "";
6
7    [JsonIgnore]
8    public string InternalToken { get; set; } = "";
9}
10
11string json = JsonConvert.SerializeObject(new UserProfile
12{
13    Name = "Mark",
14    InternalToken = "secret-value"
15});
16
17Console.WriteLine(json);

The namespace differs, but the intent is the same.

Property Versus Field

In many .NET models, serialization focuses on public properties. Public fields may or may not be included depending on serializer settings.

For System.Text.Json, fields are not serialized by default unless you enable field inclusion. That means adding [JsonIgnore] to a field may have no visible effect if the serializer would not have included the field anyway.

1using System.Text.Json;
2
3public class Sample
4{
5    public string VisibleProperty { get; set; } = "value";
6    public string PublicField = "field";
7}
8
9var options = new JsonSerializerOptions
10{
11    IncludeFields = true
12};
13
14Console.WriteLine(JsonSerializer.Serialize(new Sample(), options));

If IncludeFields is enabled, then [JsonIgnore] on a field becomes relevant.

Attribute Versus Global Options

Sometimes you do not want to decorate the model itself. Both major serializers also support global rules. For example, you might ignore all null values or customize naming, but model-level [JsonIgnore] remains the simplest answer when the goal is "never serialize this member."

Use attributes when the ignore rule is intrinsic to the model. Use global options when the rule belongs to one output context only.

Common Pitfalls

• Mixing up the Newtonsoft.Json and System.Text.Json versions of [JsonIgnore].
• Assuming fields and properties follow the same serialization rules in every serializer configuration.
• Ignoring a member for output without thinking through whether deserialization behavior should also change.
• Using serialization attributes to handle endpoint-specific DTO differences that should really be modeled separately.
• Forgetting that global serializer options may override assumptions about what gets written.

Summary

• '[JsonIgnore] is the JSON counterpart to [XmlIgnore] in .NET.'
• Use the attribute from the serializer you actually use: System.Text.Json or Newtonsoft.Json.
• 'System.Text.Json also supports conditional ignore rules with JsonIgnoreCondition.'
• Properties and fields are handled differently, especially when IncludeFields is involved.
• If ignore rules vary by API or output context, separate DTOs may be cleaner than one heavily annotated model.