The browser and the server have different strengths. Decide where a task runs based on what data it needs, what must remain private, and what a user should be able to verify.
Good browser-side work
A color contrast calculation only needs two color values and a published formula. A UTM builder only needs the URL and campaign fields the visitor entered. Running these in the browser can make feedback immediate and avoid sending draft data to a server. It also reduces infrastructure needs for a small utility site.
Browser code is visible and editable by the visitor. It cannot safely contain an API secret or make an authorization decision on its own. Treat local storage as convenient persistence, not as a secure place for sensitive credentials.
When the server is necessary
A live metadata inspector must fetch another website's HTML, deal with redirects and timeouts, parse the response, and defend against requests to private network addresses. A browser-only form cannot reliably fetch arbitrary sites because of cross-origin restrictions. That is why a manual Open Graph preview should say clearly that it does not crawl a URL.
Server-side work is also appropriate for trusted operations such as payments, authenticated changes, and storing shared data. Validate input at the boundary and keep credentials on the server.
Choose deliberately
List the data the feature needs and who should be able to see it.
Check whether the browser can obtain that data legally and reliably.
Keep secrets and access checks on the server.
Tell users when their input leaves the browser.
Sources and further reading
Primary documentation and references used to support this guide.