What stays in your browser: how GenShelf generators handle privacy
12 min read · Written by the GenShelf editor · Updated August 2026
Most “free generator” sites ask for an account, or they send what you type to a server so a spinner can come back with a result. GenShelf is built the other way: if the browser can do the job, the browser does the job. This article is the map of that design — what stays on your device, what this site never sees, and how you can check for yourself.
Why on-device generation is the default
A password, a UUID, a UULE string, and an invoice PDF do not need a GenShelf database. Sending them to a server would add latency, an account wall, and a copy of a secret you did not mean to share. The Web Crypto API, Canvas, and ordinary JavaScript are enough. I would rather ship a slightly simpler tool than collect email addresses to “process” a UUID.
That choice is also how you should judge other generator sites. If a password tool cannot explain whether crypto.getRandomValues runs locally, treat the output as untrusted until you know.
What each tool does with your input
| Tool | Runs in the browser | Remembered on this device |
|---|---|---|
| Password | Yes — Web Crypto | No |
| UUID | Yes | No |
| UULE encode/decode | Yes | No |
| Word counter | Yes — text never uploaded | No |
| QR code + logo | Yes — image stays local | No |
| Color palette | Yes — including image extract | Share links are in the URL, not a server account |
| Invoice | Yes — PDF via print dialog | From details, logo, and currency in localStorage only |
| Fake names / usernames / hashtags / lorem | Yes | No |
localStorage is still on your computer. It is not a GenShelf account. Clear it from the invoice form, or in the browser’s site data settings, if you share the machine.
How to verify nothing was uploaded
- Open DevTools → Network, then generate a password or a UULE.
- You should not see a request that contains the secret, location, or invoice line items as form data or JSON. Page loads, fonts, and (if enabled later) ad scripts are unrelated to the generator payload.
- For QR logos and invoice logos, the file is read as a data URL in memory. It is not posted to an upload endpoint.
Hosting still receives normal request logs (IP, URL, user agent) like any website — that is how the page is served. Those logs are not a copy of the password you just generated. Details are on Privacy.
What this model does not claim
- A stolen laptop still has your clipboard and localStorage. On-device is not the same as encrypted-at-rest in a password manager.
- Browser extensions can read a page. GenShelf cannot stop a malicious extension from seeing a generated password.
- Ads, if they are turned on after publisher approval, are third-party scripts with their own cookies. They do not receive generator output from GenShelf code, but they are not “the generator.”
If a future tool truly needs a server, it will be obvious on that page and in Privacy — not hidden behind a spinner. Until then, open a tool, get the output, and leave. That is the product.
Related reading: strong passwords, staging data privacy, and how the tools are built.
Try it on GenShelf: All GenShelf tools
Related guides
- Staging data privacy: fake names, IDs, and demo hygiene that won’t bite youKeep real customers out of screenshots, seed realistic fixtures, and scrub staging before every demo.
- How to create a strong password (and remember it)Length, randomness, password managers, and what to avoid — practical advice you can apply today.
- Freelance invoicing that gets you paid: what to include and how to follow upInvoice anatomy, payment terms, deposits, tax lines, and a practical follow-up cadence for freelancers.