Random String / Key Generator
Generate a random alphanumeric string.
Settings
How this works
Characters are drawn with crypto.getRandomValues and rejection sampling. Symbols are off and ambiguous characters excluded by default, giving a clean string suitable for identifiers and tokens.
What the results mean
- Look-alikes excluded
- 0/O and 1/l/I are dropped so the string is unambiguous when read or transcribed.
Common problems and fixes
- The string is rejected as containing invalid characters
- Check what the destination allows. URL-safe contexts accept letters, digits, hyphen and underscore; some database identifiers must not begin with a digit; and a few systems reject strings that could be mistaken for a number. Adjust the character set or regenerate until the result fits the constraint rather than escaping it later.
- I need it to be unique, not just random
- Random and unique are different guarantees. A long random string collides only with vanishing probability, which is fine for a token; a UUID or a database sequence gives you an actual guarantee, which is what a primary key needs. Use randomness for secrets, and a purpose-built identifier scheme for identity.
- Look-alike characters are causing transcription errors
- That is what the exclusion of 0/O and 1/l/I is for, and it is on by default. If a string still causes errors when read aloud or copied by hand, shorten it and group it with separators — anything intended to be typed by a person should be optimised for that rather than for maximum density.
Frequently asked questions
Can I use this for a unique ID?
For a non-critical identifier, yes — a long random alphanumeric string has plenty of entropy to avoid collisions. For a formal unique identifier in a database or protocol, a UUID is the standard and gives guarantees a random string does not.
How long should a random token be?
For anything security-relevant, at least 128 bits of entropy — roughly 22 characters from a 62-character alphabet, or 32 hex characters. Shorter is fine for a non-secret identifier where a collision is merely inconvenient. The rule is to size it against the consequence of someone guessing it, not against how it looks.
Is this good enough for an API key or session token?
The randomness is, since it comes from the browser's cryptographic source — the same class of generator server-side code would use. What matters more is where it is generated: production secrets should be created by the system that will store them, not pasted in from a browser, so treat this as suitable for development and manual credentials.
Put this on your own site
Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.
<iframe src="https://runthetests.com/embed/random-string-generator/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Random String / Key Generator" loading="lazy"></iframe>
Preview it at https://runthetests.com/embed/random-string-generator/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.