Introduction

In .NET Core and modern .NET, there usually is no replacement needed for WebUtility.HtmlDecode. The method still exists in System.Net.WebUtility, and for most applications it is the straightforward way to decode HTML entities such as &, <, and ".

The Direct Answer

If your older code used HTML decoding and you are moving to .NET Core, this still works:

1using System;
2using System.Net;
3
4class Program
5{
6    static void Main()
7    {
8        string encoded = "Tom & Jerry <b>cartoon</b>";
9        string decoded = WebUtility.HtmlDecode(encoded);
10        Console.WriteLine(decoded);
11    }
12}

Output:

Tom & Jerry <b>cartoon</b>

So if the question is "what replaces it," the answer is usually: nothing replaces it because WebUtility.HtmlDecode is already available.

Why People Think A Replacement Is Needed

The confusion often comes from moving from old ASP.NET or .NET Framework code that used System.Web.HttpUtility.HtmlDecode.

In older codebases, HttpUtility was common because System.Web was already part of the application. In .NET Core, System.Web is not the central web API surface anymore, so developers often switch to System.Net.WebUtility for basic HTML encoding and decoding.

That means the migration is often not from WebUtility to something else, but from HttpUtility to WebUtility.

What HtmlDecode Actually Does

HTML decoding converts entity references back into characters.

Examples:

• '& becomes &'
• '< becomes <'
• '> becomes >'
• '' becomes ''

That is useful when data was encoded for safe HTML display and you need the plain text value again.

Decode Only When You Actually Need Plain Text

A common mistake is decoding HTML too early and then rendering the result directly back into a web page. If the decoded value contains markup-like content, that may change how the page behaves.

For example, decoding this string:

string encoded = "<script>alert('x')</script>";
Console.WriteLine(WebUtility.HtmlDecode(encoded));

produces a plain string containing markup characters. That does not execute by itself in a console app, but it reminds you that decoding and rendering are separate concerns.

If your goal is safe HTML output, output encoding is usually the more important step than input decoding.

Handle Nulls And Data Flow Clearly

HtmlDecode is simple, but it is worth keeping the call close to the place where you actually need decoded text.

string? encoded = GetEncodedValue();
string? decoded = WebUtility.HtmlDecode(encoded);

Keeping the transformation localized makes it easier to reason about whether later code expects encoded text or plain text.

HtmlDecode Pairs Naturally With HtmlEncode

If you are migrating utility code, it helps to keep the encode and decode operations together conceptually.

1using System;
2using System.Net;
3
4string raw = "5 < 7 & 8 > 3";
5string encoded = WebUtility.HtmlEncode(raw);
6string decoded = WebUtility.HtmlDecode(encoded);
7
8Console.WriteLine(encoded);
9Console.WriteLine(decoded);

This makes it clear that HtmlDecode is part of the same WebUtility API family and not a missing feature that needs a third-party replacement.

Common Pitfalls

The biggest mistake is assuming .NET Core removed WebUtility.HtmlDecode. It did not.

Another mistake is decoding text and then injecting it into HTML without thinking about output encoding and XSS risk.

Developers also confuse HttpUtility migration issues with WebUtility availability. Those are different questions.

Finally, if your application stores already-decoded text, decoding again can produce surprising results or redundant processing.

Summary

• 'System.Net.WebUtility.HtmlDecode is available in .NET Core and modern .NET.'
• In many migrations, the real move is from HttpUtility to WebUtility.
• 'HtmlDecode converts HTML entities back into plain characters.'
• Decode only where plain text is actually needed.
• Do not confuse decoding with safe HTML output handling.