Privacy as a Feature: Your Code Never Leaves Your Machine
Your code is the most personal thing you type all day. It holds half-formed ideas, client work, passwords you meant to move, and the project you have not told anyone about yet. Most online editors treat that as cargo: the moment you type, it travels to a server, gets stored in someone else's database, and is governed by someone else's retention policy and breach history.
NitroIDE takes a different position, and it is not a policy page. It is the architecture. There is no server to send your code to.
The architecture that makes the claim true
NitroIDE has no server and no database. That sentence does most of the work in this article, so it is worth being precise about what it means.
Your projects live in your browser, in localStorage — the same machine you typed them on, under the same origin as the editor. Close the tab, restart the browser, come back on Monday: the work is still there, because it never left. There is no account to create, no sync queue to fail, and no backend that could leak a database it does not have.
This is a tradeoff stated up front, not a footnote. Code that lives only in one browser lives only in that browser. There is no cross-device sync to fall back on, and clearing that browser's site data will take your projects with it. That is why ZIP export exists: the portable copy is yours to keep, in a file you control, rather than an account you rent. Local-first means you are the backup strategy, and the honest version of this article says so instead of pretending otherwise.
What "never leaves your machine" actually means
The claim is deliberately narrow, and the narrowness is the point. It means your project files are never uploaded to a NitroIDE server, because there is no NitroIDE server side to upload them to. Your code is read and written by JavaScript running in your own browser tab.
It does not mean your code is sealed in a vault. Anything running in your browser tab can, in principle, see what that tab can see — which is why NitroIDE's own design keeps untrusted code out of the editor's origin (more on the preview sandbox below), and why the next section matters more than this one: the moment you choose to share, the rules change, and they change because you changed them.
Sharing without a server
Sharing is where most "private" tools quietly become servers. The usual flow uploads your project, stores it, and hands back an ID. Anyone with the ID asks the server for your code.
NitroIDE's share engine skips the server entirely. The Share button compresses the whole workspace into a ?code= URL parameter, and opening that link rebuilds the workspace locally in the reader's browser. Nothing passes through NitroIDE on the way, because there is no middle to pass through. The link itself is the transport, and the reader's browser is the destination.
That design has a consequence worth saying out loud: a share link IS you handing your code to whoever receives it — via the URL, not via a server. Anyone with the link can open it and read the project. URLs get pasted into chats, forwarded, screenshotted, and logged by proxies. So the rule is simple and non-negotiable: never put secrets, tokens, or passwords in a project you plan to share, and never share a link you would not want forwarded. The privacy guarantee covers the tool not taking your code. It cannot cover you giving it away.
The same URL-carried design sets a size limit, too. A very large project makes a very long URL, and very long URLs break in chats and address bars. For a demo or a tutorial example — a handful of files, one concept — that never matters. For a full application, export a ZIP and share a small, focused demo of the idea instead. The share link is for the example, not the app.
The preview sandbox: why shared code cannot touch your projects
The sharpest privacy question is not about NitroIDE's code. It is about other people's code. When you open a share link, you are running code someone else wrote. If that code could reach into your saved projects, the whole local-first story would collapse.
It cannot, by construction. NitroIDE's preview runs in a sandboxed iframe with an opaque origin, which is what keeps code in a shared link — or in a preview — from touching the reader's saved projects or the editor's localStorage. The preview cannot read your project list, rewrite your files, or exfiltrate your store, because from the browser's point of view it lives nowhere near them.
The tradeoff, stated in the embeds article and repeated here because it bites the same way: localStorage, sessionStorage, and cookies are unavailable inside the preview, and in Safari, touching them throws a SecurityError. Demo code that reads storage unguarded will crash inside the preview while working fine in a normal tab. Wrap storage access in try/catch in any code you plan to share, and the same demo runs everywhere. A sandbox that let shared code touch your storage would not be a sandbox.
There is a second edge to the same rule, on your side of the editor. localStorage has no per-key permissions: any script running on the editor's own origin could read the whole store. Never put tokens or secrets in a project at all — not because NitroIDE will leak them, but because a browser store is not a vault, and the safest secret is one that was never typed into the project in the first place.
Why this is a feature, not a missing backend
It is tempting to read "no server" as an unfinished product — the backend that has not been built yet. I read it the other way around. Every backend is a liability surface: an account database to breach, a retention policy to get wrong, a subpoena target, a bill that eventually needs paying by someone, usually the user. Removing the backend removes that whole class of failure at once. There is no NitroIDE database of your code to leak, to sell, or to lose, because the database was never built.
That also changes the relationship between the tool and the person using it. A cloud IDE needs your account because its business model needs your data to live on its servers. A local-first IDE does not. No signup wall stands between you and the editor, and no "free tier" clock starts ticking on your projects, because your projects were never anyone else's asset.
The honest summary is this: your code stays on your machine until you decide otherwise — by sharing a link, or by exporting a file. Those are your decisions, made in the open, with the consequences visible. Everything else is architecture, not a promise. And architecture, unlike a promise, cannot quietly change its mind in a terms-of-service update.
Try it
I build NitroIDE — a browser-based IDE where your code never leaves your machine: nitroide.com
⭐ If you enjoyed this, star NitroIDE on GitHub: github.com/nitroideofficial/nitroide
Frequently asked questions
Where does NitroIDE store my projects?
In your browser's localStorage, on the same machine you typed them on. There is no server and no database, so nothing is uploaded anywhere.
Can someone else's shared code read my saved projects?
No. The preview runs in a sandboxed iframe with an opaque origin, so code in a share link or preview cannot reach the editor's localStorage or your project list.
What is the catch with local-first storage?
Your projects live in one browser: no cross-device sync, and clearing site data removes them. ZIP export is the portable backup. And a share link hands your code to whoever receives it, so never put secrets in a project you plan to share.