There’s something quiet but powerful about watching a form fail. Not because it breaks, but because it catches what’s broken before it becomes a problem. We’ve all filled out a form, clicked submit, and been nudged—sometimes not so gently—by a red error message telling us what we missed. That’s validation doing its work. And when we build Razor Pages in ASP.NET Core MVC, we get to decide just how smart and safe that validation becomes.
Key Takeaway
- Validation rules in ASP.NET Core MVC Razor Pages are defined using data annotations on model properties.
- The framework uses ModelState.IsValid to verify input validity before processing.
- Client-side validation complements server-side checks, improving user experience without sacrificing security.
How Model Binding and Validation Work in Razor Pages
Model binding, at first glance, feels like magic. The form gets filled, a user clicks submit, and—just like that—every field’s value finds its way into a C# model. Our form inputs become C# properties, without manual mapping. But that magic’s got rules. (1)
Once Razor Pages maps the values, validation starts. That’s the framework checking if everything the user entered makes sense. It compares the values against data annotations—the attributes we stick on model properties. [Required], [Range], [EmailAddress]. All of ’em live as metadata right on the model. If a user forgets to fill in a required field or types a number where a date goes, the framework flags it.
We use ModelState to see if validation passed or failed. That’s the dictionary that keeps track of errors. If ModelState.IsValid returns false, we know something’s wrong. It means the form needs another look before we let the data do anything important—like hit the database or trigger a business workflow.
Model Binding Fails Gracefully—If We Let It
Some errors aren’t obvious. Say someone types “twelve” in a field expecting an integer. Or they paste a massive string where a short description belongs. Model binding doesn’t crash. It tries, then fails gently, logging the mistake inside ModelState.
That’s where we step in. We check ModelState.IsValid, and if it isn’t, we give users another shot. We show the form again with the mistakes laid bare—usually with red text and a little patience.
Using Data Annotations for Validation
We don’t need to reinvent the wheel here. ASP.NET Core gives us data annotations, and honestly, they handle most cases. We decorate model properties with simple rules that say, in plain terms, what’s allowed and what isn’t.
Here’s a sample of the ones we use the most:
- [Required]: Can’t leave this blank.
- [StringLength(50)]: Keeps text from getting too long.
- [Range(1, 5)]: For scores, ratings, or any number with limits.
- [EmailAddress]: Checks format without being too strict.
- [Compare]: Ensures one field matches another (like passwords).
All these annotations do two things: they check input, and they tell users what went wrong when input fails. We can set custom error messages, too. That’s helpful—because “Field X is invalid” doesn’t help anyone.
We’ve found that being clear in these messages—saying exactly what to fix—cuts form abandonment in half. People don’t mind fixing a mistake, but they hate guessing what went wrong.
Binding Inputs and Displaying Errors in Razor Pages
On the page itself, we wire up inputs with the asp-for tag helper. That’s the part that connects the form field with the model. When a user types into an input bound to Movie.Title, the value goes right into the Title property when the form posts back.
We add error messages right beneath the inputs using asp-validation-for. This is where Razor Pages shines. The error shows up exactly where the problem is. No hunting. No scrolling. Just a simple message under the box that needs fixing.
Here’s a list of what we usually include in every Razor Page form:
- <input asp-for=”PropertyName” />
- <span asp-validation-for=”PropertyName”></span>
- <form method=”post”> (so we don’t send data through the URL)
- <button type=”submit”>Submit</button>
That combo keeps the experience smooth. If validation fails, the user sees what needs fixing without losing anything they typed. The page re-renders with data still in place, errors clearly shown, and inputs ready for correction.
Handling Validation in Page Handlers
Our OnPost methods live in the code-behind. They’re quiet gatekeepers. Every time someone clicks the submit button, the page handler steps up and checks ModelState.IsValid.
Here’s what we usually see:
csharp
CopyEdit
public IActionResult OnPost()
{
if (!ModelState.IsValid)
{
return Page();
}
// Input passed validation
// Do something useful here
return RedirectToPage(“Success”);
}
This pattern protects our logic. Without it, we risk bad data slipping through. A malformed email, an empty string, or even malicious input could sneak in and cause problems down the line. We’ve seen issues escalate from one unchecked field, so we don’t skip this step.
We treat the return Page(); call not as failure but as feedback. It gives users a way to fix their input without starting over. That matters. It keeps the experience smooth and respectful.
Client-Side Validation: Faster, But Not Safer
Client-side validation is about speed. It gives users feedback before the server even gets involved. Required fields, number ranges, email formats—all checked with JavaScript in the browser.
We use built-in ASP.NET Core client-side validation libraries that support unobtrusive validation using data attributes. They read our data annotations and enforce the same rules the server does. This keeps things consistent. It also makes the form feel smart.
But we never trust it alone. Users can disable JavaScript. Or worse, send fake requests straight to the server. That’s why we always validate on the server too. Client-side checks improve experience, not security.
Here’s what we get from client-side validation:
- Immediate feedback (without a full page reload)
- Fewer unnecessary postbacks
- Better form completion rates
But again, server validation is the gatekeeper. We never skip it.
Custom Validation for Unique Rules
Sometimes the built-in attributes aren’t enough. Business rules get weird. Maybe an event date must be after today. Or a string can’t contain certain words. Or two dates must fall within 90 days of each other.
We build custom validation for that. One way is to extend ValidationAttribute and override IsValid. Another is to implement IValidatableObject and return ValidationResult objects in Validate().
Here’s a custom attribute that checks if a date’s in the future:
csharp
CopyEdit
public class FutureDateAttribute : ValidationAttribute
{
public override bool IsValid(object value)
{
if (value is DateTime date)
{
return date > DateTime.Now;
}
return false;
}
}
We add it like this:
csharp
CopyEdit
[FutureDate(ErrorMessage = “The date must be in the future.”)]
public DateTime EventDate { get; set; }
This gives us flexibility. We can enforce all kinds of rules this way without cluttering up the page logic. Validation stays where it belongs: close to the model.
Validation Summary and Error Formatting
Some forms get long. Think 10 or 15 fields, maybe more. In those cases, users like seeing all errors at once.
That’s what ValidationSummary is for. It shows every validation error at the top of the form. It doesn’t replace the individual field errors—it complements them.
We add it with:
html
CopyEdit
<validation-summary asp-validation-summary=”All”></validation-summary>
This works great for accessibility. Screen readers can hit the list first. It also helps when multiple fields fail. The user sees the full scope without scrolling down, fixing one thing at a time.
We also style these errors so they’re hard to miss. Red text, maybe a border or background highlight. Not flashy—just clear.
Input Sanitization and Security
Validation isn’t just about clean data. It’s also our first wall against attacks. People might try to inject scripts, submit malformed strings, or overload fields with garbage data. (2)
ASP.NET Core helps by encoding outputs in Razor automatically. But we still validate input. Especially if we’re storing it, sending it somewhere else, or using it in queries.
We also apply length limits using [StringLength] or [MaxLength]. This prevents buffer overflows and keeps our data tidy.
Here’s a quick checklist we follow for security:
- Sanitize HTML input (if allowed)
- Limit string lengths
- Reject unexpected formats
- Validate email and phone numbers properly
- Avoid using input directly in file paths or queries
We’ve learned the hard way—bad input can break more than just the UI.
Common Validation Pitfalls
Sometimes we think we’ve got validation locked down, but bugs sneak through. These are a few common mistakes we’ve run into:
- Forgetting to check ModelState.IsValid
Easy to miss, but it opens the door to invalid data. - Mismatch between client and server rules
If the browser allows something that the server rejects, users get confused. - Not using asp-for consistently
This breaks model binding and makes error messages unreliable. - Over-customizing errors
Too much formatting or hiding errors behind tooltips confuses users. - No fallback for disabled JavaScript
If client-side validation fails silently, users might never know what’s wrong.
Avoiding these doesn’t take much. Just attention and testing.
Practical Advice for Razor Page Validation
We’ve built dozens of Razor Pages that take user input. Some were for registration, others for product entry or internal admin forms. What worked best was this:
- Keep the model simple and focused.
- Use [Required] on every field you truly need.
- Use [StringLength] to avoid overflows.
- Validate on both client and server.
- Don’t rely only on annotations—use custom logic when needed.
- Test weird inputs. Stuff like emojis, quotes, and super-long strings.
It’s not about being perfect. It’s about building trust—between us, our users, and the system. When a form works like it should, people notice. When it fails gracefully, they remember.
That’s how we keep our pages sharp, safe, and honest. We validate like it matters—because it does.
FAQ
What is input validation in ASP.NET Core MVC Razor Pages?
Input validation checks if the data users enter into your web forms is correct and safe. In ASP.NET Core MVC Razor Pages, you can set up rules that automatically check things like required fields, email formats, and number ranges before your app processes the information.
How do I add basic validation rules to my Razor Pages model?
You add validation attributes directly to your model properties. For example, use [Required] for mandatory fields, [EmailAddress] for email formats, and [Range] for numbers within specific limits. These attributes tell ASP.NET Core what rules to follow when checking user input.
What’s the difference between client-side and server-side validation in Razor Pages?
Client-side validation happens in the user’s browser before they submit the form, giving instant feedback. Server-side validation runs on your web server after form submission. ASP.NET Core MVC Razor Pages automatically handles both types to keep your app secure and user-friendly.
How can I display validation error messages to users in Razor Pages?
Use validation tag helpers like asp-validation-for in your Razor Pages to show error messages next to form fields. You can also use asp-validation-summary to display all errors at once. These helpers automatically show messages when validation fails.
Can I create custom validation rules for my ASP.NET Core MVC application?
Yes, you can build custom validation attributes by inheriting from ValidationAttribute class. This lets you create specific rules for your business needs, like checking if a username already exists or validating complex data formats that built-in validators can’t handle.
How do I validate file uploads in ASP.NET Core Razor Pages?
Use attributes like [MaxFileSize] and [AllowedExtensions] on your file upload properties. You can also check file types and sizes in your page handler methods. Always validate files on the server side since users can bypass client-side checks.
What happens when validation fails in my Razor Pages application?
When validation fails, ASP.NET Core automatically returns the user to the same page with error messages displayed. The ModelState.IsValid property becomes false, so you can check this in your page handlers to decide what to do next.
How can I validate related data across multiple form fields in Razor Pages?
Implement IValidatableObject interface in your model class to create validation rules that check multiple properties together. You can also use custom validation attributes that compare different fields, like ensuring a “confirm password” field matches the original password field.
Conclusion
In our ASP.NET Core MVC Razor Pages apps, validating input is a critical step we can’t afford to skip. We start by defining clear rules on our model properties, then rely on both client-side and server-side validation to catch issues early.
This process helps us protect our data, improve user experience, and avoid security risks. When we follow these best practices, we empower ourselves to build safer, more reliable web applications that handle user input with confidence.
Want to take these skills further? Join the Secure Coding Practices Bootcamp to level up your secure development game with hands-on training, expert guidance, and real-world coding sessions.
Related Articles
- https://securecodingpractices.com/secure-coding-in-c-net/
- https://securecodingpractices.com/validating-user-input-in-javascript/
- https://securecodingpractices.com/asp-net-core-security-best-practices-checklist/
References
- https://www.learnrazorpages.com/razor-pages/model-binding
- https://www.learnrazorpages.com/razor-pages/validation
