Developer Tools
The seven that end up in a config file, a database column or a request header — rather than in somebody's memory.
All 7 tools
- Random String GeneratorAny length, any character set, in bulk.
- UUID GeneratorVersion 4 UUIDs, single or by the hundred.
- API Key GeneratorPrefixed keys in common formats.
- Secret Key Generator128 to 512-bit secrets in hex or Base64.
- JWT Secret GeneratorHS256, HS384 and HS512 signing secrets.
- Salt GeneratorRandom salts for password hashing.
- Hash GeneratorSHA-256, SHA-384 and SHA-512 in-browser.
Where each one ends up
| It goes in | Use |
|---|---|
| An environment variable your app signs with | Secret Key or JWT Secret |
| A request header a client sends you | API Key |
| A column next to a password hash | Salt |
| A primary key or an event ID | UUID |
| A test fixture, a seed, a throwaway token | Random String |
| A checksum you are verifying by hand | Hash |
What this page is
Not a category of its own, but a cross-section. These seven are drawn from Random Generators and Keys & Secrets on one criterion: the value ends up somewhere in a system rather than in a person's head.
Everything a human has to remember lives under Password Tools instead.
Why in-browser matters more here
A generator that runs on a server has to receive the value before it can show it to you. For a throwaway string that is merely untidy. For a signing key that is about to protect every session your application issues, it means the key existed somewhere you cannot audit before it ever reached you.
Everything on this site is produced by crypto.getRandomValues() in your own browser. There is no request to log, no database row and no backup — which is a property of the architecture rather than a promise, and the privacy page explains how to confirm it in about a minute.
Two things that are deliberately missing
There is no API. An API means a server, and a server means your key material travelling somewhere before you see it. If you need generation inside a build step, your language's standard library already has a cryptographically secure random source — that is the same thing these pages call.
There is no file hashing either. shasum -a 256 and Get-FileHash already do it offline, without a web page in the middle.
Which specification each one follows
- UUID — RFC 9562, including the v7 monotonic counter in §6.2.
- JWT Secret — RFC 7518 §3.2, which makes the minimum key size a MUST.
- Salt — RFC 9106 §3.1 for the 16-byte recommendation.
- Random Code — Crockford's Base32, for the readable alphabet and the check symbol.
- Hash — RFC 1321's own test vectors for MD5; the browser's implementation for SHA.
Where a page quotes a specification it links to it and quotes the wording, so you can check that the tool does what the standard actually says rather than what a blog post said it says.
Frequently asked questions
How do I generate the same values in code?
Use your language’s secure random source, which is what these pages call. In Node.js, crypto.randomBytes(32).toString("hex") gives a 256-bit key and crypto.randomUUID() a version 4 UUID. In Python, secrets.token_hex(32) and uuid.uuid4(). From a shell, openssl rand -hex 32. Avoid Math.random() and Python’s random module, which are not built for secrets.
Where should a generated key be kept?
In an environment variable or a secrets manager, read by the application when it runs. Keep it out of source control — add your .env file to .gitignore before the first commit — and out of anything shipped to the browser, where every visitor can read it. If a key does reach a repository, treat it as leaked and replace it.
Which of these values are safe to make public?
UUIDs and salts: a UUID is an identifier, and a salt is stored in plain sight beside its hash. A hash of public data is public too. Secret keys, JWT secrets and API keys must stay private, and so must a random string once it is used as a token. A UUID should never be the only thing that grants access to what it names.
Do these tools work without an internet connection?
Once a page has loaded, yes. Generation runs in the page itself and makes no network request, so you can disconnect and keep generating. Loading the page in the first place needs a connection; generating does not.