Server-Side vs Client-Side
Where Code Runs: On the Server or in the Browser
Server-side vs client-side describes where a piece of web code runs. Server-side code runs on the web server before anything is sent to the visitor, while client-side code runs in the visitor's browser after the page has arrived.
When a visitor enters an address, their browser sends a request to a server. The server finds the right files or runs a program to build the page, then sends the result back. The browser displays what it received and may run more code of its own. The roles of the people who build each side are described in frontend vs backend development.
How Server-Side Code Works
Server-side code is written in languages such as PHP, Python, Ruby or Node.js. It runs on the hosting server, so visitors never see the source code. They receive only the output, usually HTML.
Server-side code is the natural place for work that needs private data or a shared database. Checking a password, saving a comment or loading the latest products from a store database all happen on the server. The browser cannot be trusted with those tasks, because anything it receives can be inspected and changed.
This split is one reason sites are described as static or dynamic. Dynamic sites rely on server-side code for most pages. The server also uses the host's processor, memory and installed runtime, so heavy processing needs more resources than serving plain files.
How Client-Side Code Works
Client-side code runs in the browser, usually written in JavaScript. The browser downloads the script with the page and runs it on the visitor's device. Common examples include image carousels, form checks and menus that open and close without a page reload.
Client-side code reduces the work on the server, because the visitor's device does the processing. Its weakness is that the visitor controls the environment. Anything in a script can be read, altered or disabled, so client-side checks should never be the only protection for sensitive actions.
A Login Form That Uses Both Sides
Take a login form. JavaScript in the browser can check that the email field contains an @ sign and that the password is not empty. This gives the user fast feedback without a round trip to the server.
The server then checks the password against the stored record, starts a session and decides what the user may access. If the browser check is skipped, for example by a user who turns off JavaScript, the server check still stops bad data. The server therefore remains the final authority.
Frequently asked questions
Is JavaScript always client-side code?
No. JavaScript is most often used in the browser, but it can also run on a server through Node.js. The question is not the language but where the code executes, and the same language can be used on either side.
Why does server-side code matter for hosting?
Server-side code runs on the host's machine, so it uses the server's processor, memory and installed runtime. Plans with limited resources or outdated runtimes can slow down or break dynamic sites, even when the front end looks correct.