Text & everyday tools · Password Generator
How a browser-only password generator works (and how to verify it)
· How it works
passwords privacy browser-tools
Walks through what a page must do to generate a passphrase with no server involvement — load the wordlist, draw random numbers, pick words — and gives three checks anyone can perform to confirm nothing was sent.
Who else saw your new password? — the question every online generator should be able to answer with 'nobody'
The useful trust question is not whether an online generator calls itself private; it is what happens to the generated bytes after selection. ToolAcre’s repository gives a bounded answer: generation occurs in the tab, the result is rendered as text, and browser tests assert that pressing Generate creates no network request. The product registry disables analytics and advertising on the credential page.
This evidence does not prove that nobody on the device can see the value. Browser extensions, screen capture, malware and a compromised operating system sit outside the page’s control. The supported claim concerns ToolAcre’s code and network behavior, not the entire computer or every threat model in which the generated value might later be used.
What the repository can prove about who receives a generated value
The three ingredients are separate and inspectable. Wordlists are static same-origin text files. Web Crypto supplies random bytes. Package functions filter the selected list, draw unbiased indices and join the chosen words according to delimiter and case settings. Character mode draws from explicit classes and securely shuffles positions after guaranteeing each selected class appears.
Keeping those pieces visible helps a reviewer distinguish data loading from secret transmission. A request for `wordlists/eff-long.txt` contains public vocabulary, not the assembled passphrase. The generated value exists only after local indices select and combine entries, and end-to-end tests check that the assembled string never appears in a wordlist response.
What a server-side generator does instead — and why a password generated elsewhere has already been shared once
A server-side generator would need a request or response carrying enough information for the server to produce or deliver the secret. That is not the ToolAcre path. The page fetches public assets, then invokes the imported engine synchronously in the browser. There is no password-generation API endpoint and no request body containing the current output.
Avoid turning this contrast into a claim that all remote generators are malicious or that local execution is automatically safe. A local page still executes code and displays a credential on a device. The verifiable advantage here is narrower: ToolAcre’s application server does not receive the generated value during the Generate action.
What this browser-only generator avoids: no generation request to a ToolAcre server
Open developer tools before pressing Generate and preserve the request log. Let the default list finish loading, mark the current request count, then generate several values. The expected delta is zero. Browser tests perform this exact comparison and fail if generation adds traffic. They repeat the check for Copy because clipboard writing is also a local operation.
Do not mistake the initial wordlist download for leakage. Inspect its URL, method and body: the tests require a same-origin GET with no request body. A meaningful network review asks whether the newly assembled value appears in a URL, headers, request body or response, not whether a static application ever loads an asset.
Check two: the Content Security Policy — how a strict policy with no third-party scripts limits where data could go
The password product’s Content Security Policy restricts connections to its own origin, and its registry turns off ad and analytics providers. Source-level tests also prohibit storage writes, console logging and URL placement in code paths that can hold the credential. These controls reduce destinations available to an accidental future change and make regressions visible in review.
CSP is defense in depth rather than proof that every same-origin script is benevolent. Source inspection and browser behavior remain necessary. Check what scripts load, follow the output assignment, and verify that the only clipboard call occurs after the explicit Copy action. A badge or policy sentence cannot replace those observations.
Check three: disconnect — once the page has fully loaded, go offline and generate again; a fully browser-side tool should keep working
Offline behavior needs one qualification the workbook omitted. A selected wordlist must already be loaded into the current page. Once it is in memory, generating another passphrase performs local arithmetic and needs no request. Selecting a different uncached list while disconnected can fail because the page still needs that public static file.
A fair test therefore loads the page and desired list, disconnects, then presses Generate again. Success demonstrates that assembly is local; it does not show that every asset was bundled or that the page can make an unavailable list materialize. The wordlist loader reports download, missing-file and empty-file failures honestly instead of substituting another list.
Check three: after a selected wordlist is loaded, generation itself needs no request
These checks do not audit extensions, clipboard managers or the operating system. They also do not decide where a generated credential should be stored. ToolAcre has no vault, history, sync or autofill, and nothing about local generation recommends sending a result through chat, email or another transport.
The device must be trusted before a live credential is generated. For an untrusted or shared machine, the project’s own limitations page says to use something else. Network silence proves a property of the page action, not immunity from software with broader access to the screen or browser process.
The takeaway — the Password Generator runs the whole job on your device, and each of these checks takes under a minute
ToolAcre supports a concrete verification chain: static same-origin wordlist load, Web Crypto draw, local unbiased selection, text-only display, no request on Generate, and explicit-only clipboard writing. Registry settings remove advertising and analytics scripts from the password product, while tests search for storage and logging regressions.
Repeat those checks rather than trusting the conclusion secondhand. The result should be a scoped statement about this build and code path. It should never become “this password is safe everywhere,” and it should not blur a generator with the manager or policy that governs what happens next.