The riskiest moment in using a free online tool is the paste. Most privacy guides rank
browser extensions and VPNs and skip the question you actually face several times a
week: when I paste a secret into a web page, where does it go? This guide covers the
tools where the answer is verifiable, because the entire implementation runs in your
browser with no network code at all.
What client-side actually means, and how we checked
A grep across our password generator, hash generator, and JWT decoder finds no fetch
call, no axios import, and no XMLHttpRequest. Nothing in those components can send
your input anywhere, because nothing in them opens a network connection. The page is
delivered once, and every computation after that happens locally.
That claim is auditable. Open your browser devtools, switch to the network tab, and use
the tool. You will see the initial page load and then silence. Server-side tools,
where your input travels to be processed, cannot offer that test.
The limit is equally real. Client-side code protects your data from the tool operator
only as far as the page itself is trustworthy. If your browser or the site delivery
path is compromised, generated values can be observed regardless of where the code
runs. Treat browser-side tools as a large improvement over pasting secrets into
random websites, and as no replacement for an OS-level password manager.
Password generation, from the source
The generator draws from four pools you can toggle: 26 uppercase letters, 26 lowercase
letters, 10 digits, and 26 symbols. Defaults are a length of 16 with uppercase,
lowercase, and digits enabled and symbols off. That default pool is 62 characters, and
16 characters from a uniform 62-character pool carry about 95 bits of entropy. Turn
symbols on and the pool grows to 88, pushing the same length to about 103 bits. The
length slider runs from 6 to 64, and the batch slider generates 1 to 20 passwords at
once.
Randomness comes from crypto.getRandomValues filling an array of 32-bit unsigned
integers, one per character, each mapped into the pool with a modulo operation. Two
facts follow, and both belong in an honest guide. First, getRandomValues is the
platform cryptographic source, and using it per character is the right primitive.
Second, a 32-bit value mapped by modulo into 62 or 88 slots carries a tiny modulo
bias, because 2 to the 32nd power divides evenly by neither. The bias is astronomically
small and irrelevant in practice, and we say it exists rather than pretend otherwise.
Preferences persist in localStorage under two keys, one for length and one for the
character set toggles. Generated passwords are never written to storage. They exist in
memory until you copy one, and the copy lands in your clipboard, where clipboard
history features may retain it. Clear your clipboard after pasting if that history is
enabled.
The strength meter that can be wrong in your favor, and against you
The meter scores five checks: length at least 8, length at least 14, any uppercase,
any digit, any symbol. Five labels run from Very Weak to Very Strong. Because the
score counts character classes present rather than entropy, it produces one failure
case you should know. A 40-character all-lowercase password scores 2 out of 5 and is
labeled Moderate, while carrying about 188 bits of entropy, far beyond any realistic
attack. Length dominates, and the meter underweighs it.
The reverse also holds. An 8-character password with one uppercase, one digit, and one
symbol scores 4 out of 5 and looks Strong, while drawing from fewer than 95 effective
bits, and real-world cracking rigs work through short mixes quickly. Read the meter as
a composition check, and set the length slider to at least 16 regardless of what the
label says.
Hashing and tokens without a server round trip
The hash generator computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 in real time,
the SHA family through the browser's crypto.subtle.digest, with output sizes of 160,
256, 384, and 512 bits respectively. Two honest warnings ship with that list. MD5 and
SHA-1 are collision-broken and must not be used for anything security-related. They
remain useful for non-security fingerprints, such as matching two large text blobs
quickly.
The JWT decoder belongs to the same pattern. Pasting a session token into an unknown
decoder site is a credential leak with extra steps. Decoding locally, where the token
never crosses the network, turns that inspection into a zero-risk operation.
There is also a negative example in our own codebase, and it is instructive. The color
palette generator seeds random palettes with Math.random, which is fine for colors and
unacceptable for secrets, because Math.random is predictable. Right tool, right
randomness source. Secrets get getRandomValues, palettes get anything.
Your weekly privacy routine, in order
1. Generate passwords locally at length 16 or more, one per account, symbols on where
sites allow them.
2. Store them in a manager, and clear the clipboard after pasting on shared machines.
3. Verify file or text integrity by hashing locally, and compare digests out of band.
4. Decode JWTs and inspect tokens only in local tools, never in sites of unknown
ownership.
5. Once a month, open devtools network tab on any security tool you use and confirm
the silence.
Checklist for adopting a browser-side tool
- Network tab shows no requests during use.
- Source is readable and uses crypto.getRandomValues for secrets.
- Generated values are not persisted to storage.
- Clipboard hygiene handled after copying.
- Colliding algorithms like MD5 and SHA-1 kept away from security purposes.
Convenience and privacy usually pull in opposite directions. Local computation removes
the tension for a specific class of tools, and the network tab lets you verify the
claim yourself in under a minute.
Which class of secret do you still paste into websites, tokens, passwords, or client
IDs? Generate your next batch with our
[password generator](https://webrecast.com/en/password-generator) and watch the
network tab while it runs.
