Client-side feedback is a check in the browser that helps the user quickly. Server-side validation is a check on the server that protects the data, because the user cannot bypass it.
This lesson is part of web development without assessed-project substitution. It uses a fictional sign-up form, not any student’s project.
What does each check do?
| Client-side feedback | Server-side validation | |
|---|---|---|
| Runs where | In the user’s browser | On the server |
| Main purpose | Fast, friendly feedback | Protect stored data |
| Can the user skip it? | Yes | No |
| Speed | Immediate | After the data is sent |
| Enough alone? | No | Needed for trust |
The browser is under the user’s control. Anything the browser checks can be changed, switched off or sent around.
Worked example: a class club sign-up form
A fictional club page asks for an age from 13 to 17. The HTML box is marked required, and JavaScript shows “Age must be 13 to 17” if the value is outside the range.
A user types 12 and sees the message. The form does not send. That is client-side feedback doing its job.
Now a different user turns off JavaScript, or sends the data without using the page at all, and submits 12. Nothing in the browser stops it. The data reaches the server.
| Situation | Browser check | Server check | Result |
|---|---|---|---|
| Honest user types 12 | Shows message | Never reached | Helpful feedback |
| Browser check skipped, 12 sent | Skipped | Rejects 12 | Data stays clean |
| Server has no check | Skipped | None | 12 stored as valid |
The third row is the danger. The data looks valid because the page looked careful, but nothing trustworthy checked it.
The mistake: treating the message as the safety
The common belief is “my page shows an error, so invalid data cannot get in.” The error message is a convenience for honest users, not a barrier.
| Claim | Correct statement |
|---|---|
| “JavaScript validation keeps bad data out” | It helps users, but can be bypassed |
| “If the page shows an error, the data is safe” | Only a server check makes data safe |
| “Server checks make browser checks useless” | Browser checks save time and reduce errors |
In an exam answer, name both checks and give a reason for each. One sentence for each is enough: the browser check gives quick feedback, and the server check protects the data.
What should the server re-check?
Everything the browser checked, plus anything the browser cannot know. For the sign-up form that means the age range again, that the field is a whole number, and that the name is not already on the club list.
The last item shows a limit of the browser: it does not hold the list of existing members, so only the server can check for a duplicate.
Check yourself
A voucher box accepts 6 characters. JavaScript shows an error for a 5 character code. Explain why the server must still check the length, and name one check only the server can do.
Answer
The browser check can be skipped, for example by turning off JavaScript or sending data directly, so a 5 character code could still arrive. The server must therefore check the length again.
Only the server can check whether the code exists in the list of issued vouchers, or whether it has already been used, because that list is stored on the server.
What to study next
Test that your page still works when the mouse is not used in testing a small page with keyboard-only interaction. For test data ideas, revisit testing interaction and data validation.
For guided practice with a teacher, see online one-to-one Computer Science tuition.