The line that matters
Frontend code runs on the user's device, inside their browser. Backend code runs on a machine you control. That's the whole distinction, and every practical consequence follows from it.
The consequence that matters most: anything on the user's device can be read and changed by that user. Not by a hacker — by any curious person with developer tools open. Which means frontend code can never be trusted with a secret or with a final decision.
Who owns what
| Responsibility | Side | Why |
|---|---|---|
| Layout and styling | Frontend | It's about the device it's shown on |
| Instant feedback on a form | Frontend | Waiting for a server to say a field is empty is a bad experience |
| Deciding if a password is correct | Backend | The check and the stored value must both be out of reach |
| Deciding what a user may see | Backend | Hiding a button hides a button, not the data |
| Talking to the database | Backend | Credentials can't exist on a user's device |
| Charging a card | Backend | Amounts sent from a browser can be edited |
| Sending email | Backend | Mail credentials are secrets |
Why the line looks blurry now
Modern frameworks let you write both sides in one language, in one project, sometimes in one file. That's a genuine convenience and a genuine source of confusion, because the file no longer tells you where the code runs.
Frameworks handle this with explicit markers — a directive at the top of a file, a naming convention, a folder. Learn your framework's marker early, because the security rule hasn't changed at all: a function that reads a secret must never end up in a bundle shipped to a browser.
// Before writing any function, answer one question:// Does this need something the user must never have?//// Database credentials -> backend// API keys -> backend// Another user's data -> backend// The current scroll pos -> frontend// Whether a menu is open -> frontendPlacing a new feature
- Ask what the feature needs access toSecrets, other users' data, or money mean backend. No exceptions worth taking.
- Ask how fast it must feelAnything that should respond within a keystroke belongs on the frontend — as a convenience layered over a backend check.
- Assume both, thenMost features are a frontend layer for responsiveness plus a backend layer for truth. Duplicated validation isn't waste; it's the design.
Common mistakes
- Storing an API key in frontend code, or in an environment variable that gets bundled into it
- Enforcing permissions by hiding UI
- Trusting a price, a user ID, or a role that arrived from the browser
- Assuming a shared language means a shared trust boundary
Key takeaways
- The split is about which computer runs the code, and everything follows from that
- Anything on the user's device is readable and editable by the user
- Secrets, permissions, and money live on the backend without exception
- Duplicated validation on both sides is correct, not redundant
Try it yourself
Pick a feature in your product and list what it touches. Mark each item as "safe for a stranger to see" or not. Everything in the second column defines the backend half of that feature.