Form validation: server-side vs client-side best practices

Someone submits your form with an invalid email address. Your form accepts it. The welcome email bounces. They never hear from you. Someone else submits with missing required fields. The form still goes through. Your team has incomplete data. Both of these failures happen because validation is missing or wrong.

Validation is the process of checking that form data is valid before accepting it. It happens in two places: the browser and the server. Both matter. This article covers how validation works, why you need both, and common mistakes.

What is validation?

Validation checks that the data in a form meets your requirements. Required fields have values. Email fields contain an @ symbol. Phone fields contain only numbers. File uploads are under the size limit.

Without validation, bad data enters your system. Your backend crashes. Your email service rejects messages. You waste time cleaning up dirty data.

Validation happens in two places: client-side (in the browser, before submission) and server-side (on your server, after submission). Both are necessary.

Client-side validation

The browser can check form data before sending it. HTML has built-in validation attributes. JavaScript can validate too.

HTML validation

<input type="email" required> validates that the field has a value and looks like an email. The browser shows an error message if the user tries to submit an invalid form.

HTML validation attributes include required to ensure the field must have a value, min/max for numbers to keep values within range, minlength/maxlength to enforce character counts, pattern to match regular expressions, and type to validate field type itself. For example, type="email" checks format while type="number" rejects non-numeric input.

HTML validation works immediately without JavaScript needed and provides good error messages from the browser with mobile keyboards that adjust based on field type. The disadvantages are that browser error messages are generic and sometimes unclear, you cannot customize them without JavaScript, and different browsers show different messages.

JavaScript validation

For more control, validate with JavaScript using function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } and form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. JavaScript validation lets you write custom rules, show custom error messages, and validate fields as the user types for real-time validation. Disadvantages include requiring JavaScript (not reliable for security), requiring more code to maintain, and potentially showing errors before the user finishes typing if you validate on input event.

Server-side validation

After the form is submitted, the server checks the data again. This is where real security happens.

Never trust client-side validation. Someone can disable JavaScript. Someone can intercept the request and modify the data. Someone can use curl or a tool to submit bad data without going through your form at all.

Server-side validation is the only protection you have. It is not optional.

When the server receives the form submission, check that required fields are present, validate email format, phone format, and URLs, check that numbers are within expected ranges, verify file uploads are the right type and size, ensure data length is not too long, and sanitize data to prevent injection attacks. If validation fails, send an error response so the form should not be processed and the user is told what is wrong. Server-side validation is slower because the user has to wait for a response, but it is reliable and secure, so always do it.

When to use each type of validation

Client-side validation is for user experience. It tells the user immediately if something is wrong. They do not have to submit the form to find out an email is invalid.

Server-side validation is for data integrity and security. It ensures bad data never enters your system.

Use both. Client-side validation for speed and feedback. Server-side validation for safety and security.

Common validation mistakes

Only doing client-side validation

Someone disables JavaScript and your validation is gone. Someone uses curl to POST bad data and your validation never runs. You end up with garbage in your database.

Always validate on the server. Client-side is extra.

Validating too strictly

Your email validation is so strict that real emails fail. Your phone validation only accepts US format and rejects international numbers. Your name field rejects hyphens, apostrophes, and other valid characters.

Test your validation against real data. Ask users from other countries to test. Make validation rules as permissive as possible while still catching bad data.

Not showing clear error messages

"Invalid input." What is invalid? Which field? What should they do?

Error messages must be specific: "Email must be between 5 and 254 characters." "Phone must be 10 digits." "Password must contain at least one number."

Show the error next to the field that caused it. Do not hide errors in a summary list where the user has to hunt for them.

Validating sensitive data on the client

Do not send credit card numbers or passwords through client-side validation. Do not show them in browser console. Do not log them.

Validate sensitive data only on the server, over HTTPS.

Not validating file uploads

Someone uploads a 100 megabyte file. Your server runs out of storage. Someone uploads an executable file. Your server catches a virus.

Validate file type and size on the server. Check that the file is actually the type it claims to be. Do not trust the file extension or MIME type alone.

Real-time validation versus submit-time validation

Real-time validation checks each field as the user types. The user sees an error message immediately if they enter something wrong. They can fix it right away.

Disadvantage: If you show errors too early, the user gets frustrated. Show errors only after the user leaves the field (on blur event), not while they are still typing.

Submit-time validation checks everything when the form is submitted. The user fills out the entire form, then sees all errors at once.

Disadvantage: The user has to go back and fix errors after they have already submitted. This interrupts the flow.

Best practice: Validate on blur (when the user leaves a field) for real-time feedback. Validate on submit as a final check. Show all errors at once if any fail.

Validation for specific field types

Email validation

Full email validation is complex (RFC 5322 is 60 pages), so for most cases, check that the value contains an @ and a domain using const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. This catches most invalid emails without being so strict that real emails fail.

Phone validation

Phone format varies by country. The US format is (123) 456-7890, the UK format is +44 20 7946 0958, and Germany uses +49 30 123456. Accept international format, strip non-numeric characters on the server, and store the phone as a string instead of a number to preserve leading zeros in some countries.

Password validation

A good password is long (at least 12 characters) and hard to guess. Do not require special characters or mixed case because these rules frustrate users and do not improve security. Good password requirements are at least 12 characters and avoiding common patterns (like "123456" or the user's name). Use a password strength meter to show the user how strong their password is.

Date validation

Check that the date is in the future or past as needed. An event registration form should reject dates in the past. A birth date form should reject dates in the future.

How WEMASY handles form validation

WEMASY forms include built-in client-side validation (required fields, email format, etc.) for immediate feedback. When forms are submitted, WEMASY's servers validate all data again before processing. This gives users fast feedback and your data is protected.

See validation features in your WEMASY plan.

Frequently asked questions