Validate on both client and server

Client and server validation solve different problems.

Client validation gives fast feedback. It can catch an empty required field before a request, point to the field, and preserve the person’s place in the form.

It cannot protect the server. A client can remove attributes, disable JavaScript, change hidden values, or send a request without using the page.

Imagine a form for reserving workshop seats:

<input name="seats" type="number" min="1" max="4" required>
<input name="workshopId" type="hidden" value="42">

The browser can check the visible number. The server must make the final decisions:

1. Parse seats as an integer.
2. Reject values below 1 or above 4.
3. Load workshop 42 from trusted storage.
4. Check that it exists and still has enough space.
5. Check that the current user may reserve it.
6. Create the reservation without allowing a race to oversell it.

Changing the hidden ID to another workshop is easy. Passing seats=4 does not prove four places remain. Format validation and business validation are different layers.

Return field errors in a shape the form can display beside the correct controls. Preserve safe values so the person can correct the request. Use a general error for a server failure rather than pretending the input was wrong.

Keep the client and server rules derived from the same contract where your stack allows it, but never skip the server check.

Use DevTools to remove max="4", submit seats=100, and confirm the server rejects it. That is the test that matters.