Introduction

string.Format in C# handles null more gracefully than many developers expect. If a formatting argument is null, the placeholder is replaced with an empty string rather than throwing a NullReferenceException. The tricky part is not the basic behavior, but how that interacts with alignment, custom format providers, and your own expectations about missing data.

Default null Behavior

If an argument passed to string.Format is null, the formatted output is just an empty string for that placeholder.

1using System;
2
3public class Program
4{
5    public static void Main()
6    {
7        string? name = null;
8        string text = string.Format("User: {0}", name);
9        Console.WriteLine(text);
10    }
11}

Output:

User:

So string.Format does not fail simply because one argument is null.

Why It Does Not Throw

Internally, formatting logic treats null similarly to an empty result instead of calling instance members on a null reference. Conceptually, it behaves like formatting String.Empty for that slot.

This is useful in UI and logging code where optional values are common, but it can also hide missing-data bugs if you were expecting a visible placeholder.

Alignment and Composite Formatting

The empty-string behavior still participates in composite formatting rules such as alignment.

1using System;
2
3string? code = null;
4string text = string.Format("|{0,10}|", code);
5Console.WriteLine(text);

Even though the value is empty, the alignment width is still applied. That can matter in tabular output or reports.

Difference from Calling Methods on a Nullable String

This is not the same as doing:

string? name = null;
Console.WriteLine(name.ToUpper());

That will throw because you are calling an instance method on null. string.Format is safer because it handles the formatting argument centrally.

Handling null Explicitly When Empty String Is Not Good Enough

Sometimes silent empty output is undesirable. In those cases, coalesce before formatting.

1using System;
2
3string? name = null;
4string text = string.Format("User: {0}", name ?? "(unknown)");
5Console.WriteLine(text);

This makes missing values obvious in logs, API traces, and support screens.

IFormattable and Custom Formatters

If the argument is not null and implements formatting interfaces, string.Format can apply format strings normally. If the object itself is null, none of that custom formatting logic runs, because there is no object instance to format.

That distinction matters when you expect custom ToString or IFormattable behavior and wonder why it did not run for missing values.

Comparison with String Interpolation

String interpolation ultimately routes through formatting rules too, so similar null behavior is common.

string? name = null;
Console.WriteLine($"User: {name}");

This also produces an empty segment for name. If you need stronger visibility for missing values, explicit fallback text is still the right answer.

Logging and Diagnostic Policy

For user-facing text, empty string may be fine. For diagnostics, it is often better to be explicit. A log line that silently drops a null value can make troubleshooting harder.

Good pattern:

string? requestId = null;
Console.WriteLine("RequestId={0}", requestId ?? "<missing>");

The formatting API is not wrong here, but your output policy should match the context.

Common Pitfalls

• Assuming string.Format will throw on null the way direct method calls do.
• Letting nulls silently disappear in logs where explicit placeholders are more useful.
• Forgetting that alignment still applies even when the rendered value is empty.
• Expecting custom formatters to run on a null object instance.
• Mixing formatting behavior with business rules about required fields.

Summary

• 'string.Format replaces null arguments with empty string output by default.'
• It does not throw just because a placeholder value is null.
• Alignment and composite formatting rules still apply to that empty result.
• Use ?? or other explicit fallback logic when empty output is undesirable.
• Choose null-display policy intentionally, especially in logs and diagnostics.