Introduction

This ASP.NET error appears when request validation detects input that looks like HTML, script, or other markup-like content in a form field. The framework is trying to reduce XSS risk by blocking suspicious request data before your action logic processes it.

Why ASP.NET Throws This Error

Classic ASP.NET request validation inspects incoming form values and rejects content that appears unsafe, such as strings containing angle-bracketed markup. This often happens when users submit rich text, pasted HTML, or code snippets.

A typical scenario is a form field like content receiving something that looks like HTML:

<p>Hello</p>

From the framework's point of view, that may be a legitimate rich-text payload or it may be an XSS attempt. Request validation blocks it early because it cannot safely assume the input is harmless.

The Safe Default: Keep Validation Enabled

The first rule is not to disable request validation globally just because one field needs special handling. The safest design is:

• keep validation on by default,
• allow rich content only where it is explicitly needed,
• sanitize that content before storage or rendering,
• HTML-encode content when you display it as plain text.

This prevents a narrow requirement from weakening the entire application.

Per-Field or Per-Action Allowance

If you intentionally accept HTML in a specific MVC model property, AllowHtml can be more precise than turning validation off for the whole request.

1using System.Web.Mvc;
2
3public class ArticleViewModel
4{
5    [AllowHtml]
6    public string Content { get; set; }
7}

In some cases, you may see action-level disabling:

1[ValidateInput(false)]
2public ActionResult Save(string content)
3{
4    // Sanitize before storing or rendering.
5    return View();
6}

That works, but it is broader than necessary. If only one field needs rich text, prefer the narrowest allowance you can use.

Allowing Input Does Not Make It Safe

The most important point is that accepting HTML and trusting HTML are different things. Disabling request validation only allows the content to pass through. It does not sanitize it.

If you store and later render user-provided HTML directly, you can create an XSS vulnerability. A safer flow is:

1. accept rich content only where required,
2. sanitize it on the server,
3. store the sanitized version,
4. render it carefully.

For plain text output, encode it:

@Html.Encode(Model.Content)

If the application intentionally renders sanitized HTML, use a server-side sanitization step first and only then render the trusted result.

Rich Text Is a Special Case

Applications with CMS fields, blog editors, or description boxes often need rich text. That is the valid use case for handling this error rather than fighting it.

In those cases, a clean design usually includes:

• a dedicated rich-text field,
• a sanitizer allowlist for permitted tags and attributes,
• output rules that distinguish between plain text and sanitized HTML.

The mistake is treating every input field as a rich-text field just because one form needs it.

Debugging the Source of the Error

If the error appears unexpectedly, check which form field contains markup-like content. Common sources are:

• pasted content from Word or a browser,
• hidden fields that now contain encoded HTML,
• WYSIWYG editor output,
• code snippets submitted in text boxes.

Once you identify the field, you can decide whether the application should reject it, store it as plain text, or allow sanitized HTML for that specific case.

Common Pitfalls

• Disabling request validation for the entire application instead of narrowing the exception to one field or action.
• Allowing HTML input and then rendering it later without sanitization.
• Assuming request validation is the only XSS defense you need.
• Treating all form fields as if they should accept markup.
• Forgetting that output encoding is still required when content is meant to be displayed as text.

Summary

• The error means ASP.NET request validation detected input that looks unsafe, often HTML-like markup.
• Keep validation enabled by default and allow exceptions only for fields that genuinely need rich content.
• 'AllowHtml or targeted action-level allowances are safer than disabling validation globally.'
• Accepting rich input is not enough; sanitize before storage or rendering.
• Output encoding still matters whenever the content should be displayed as plain text.