Random Text Generator

About the Random Password & String Generator

This tool generates cryptographically secure random values entirely in your browser using the Web Crypto API (crypto.getRandomValues), the same secure entropy source the browser exposes for keys and tokens — not Math.random(). It can produce strong passwords (with selectable uppercase, lowercase, digits and symbols), arbitrary random strings, random number and letter sequences, and RFC 4122 version-4 UUIDs (also via the native crypto.randomUUID where available). Because the randomness is drawn from the operating system's secure entropy pool, every value here is suitable for real-world secrets: passwords, API keys, session tokens, salts and one-time codes. For each generated password or string the tool also shows the estimated entropy in bits and an estimated offline crack time, computed from the actual alphabet size and length, so security engineers, sysadmins and compliance reviewers can verify a credential against policy (NIST and OWASP commonly cite at least 80 bits for high-value secrets) instead of relying on a vague 'Strong' label.

Is the randomness cryptographically secure — can I use these for real passwords?

Yes. Every mode (password, string, numbers, letters, words and UUID) draws from crypto.getRandomValues(), the Web Crypto API's cryptographically secure pseudo-random number generator, which is seeded from the operating system's entropy pool (/dev/urandom on Unix, CryptGenRandom/BCryptGenRandom on Windows). Unlike Math.random(), its output is not predictable from observed values, so the generated values are appropriate for passwords, API keys, session tokens, salts and one-time codes. Integer selection uses rejection sampling to avoid modulo bias, so each character is uniformly likely. As always, generate secrets on a trusted device and store them in a password manager — nothing here is transmitted to a server.

How is the entropy in bits calculated, and why does it matter?

Entropy is computed as bits = length × log2(poolSize), where poolSize is the number of distinct characters in the active alphabet and length is the number of characters generated. For example, a 16-character password from the full 94-symbol printable-ASCII set has about 16 × log2(94) ≈ 105 bits, while 8 digits (pool of 10) has only about 8 × log2(10) ≈ 27 bits. Bits of entropy is the standard, defensible measure of how hard a secret is to guess: each extra bit doubles the search space. It is far more meaningful than a colored 'Strong/Weak' bar because it lets you check a credential against an explicit policy threshold.

What does 'Meets 80-bit policy' mean?

Security guidance such as NIST SP 800-63B and OWASP recommends that high-value secrets carry enough entropy that an offline brute-force attack is infeasible; 80 bits is a commonly cited floor for important credentials, with 112–128 bits preferred for long-lived keys. When a generated password or string reaches at least 80 bits, the verdict badge turns green ('Meets 80-bit policy'); below that it warns you ('Below 80-bit policy'). To raise entropy, increase the length or enable more character classes (uppercase, lowercase, digits, symbols), which enlarges the alphabet.

How is the offline crack time estimated?

The crack-time figure assumes a fast offline attacker making about 1×10¹² (one trillion) guesses per second — a reasonable order-of-magnitude for high-end GPU rigs against a fast or unsalted hash — and that the secret is found on average after searching half the keyspace. So estimated seconds ≈ 2^bits ÷ 1e12 ÷ 2. It is a rough order-of-magnitude indicator, not a guarantee: a slow, salted KDF like Argon2 or bcrypt makes cracking dramatically slower, while a leaked plaintext or reused password makes it instant. Use the bits figure as the primary metric and the time as intuition.

How many bits of entropy does a UUID v4 have?

A version-4 UUID has 128 bits total, but 6 of them are fixed by the standard (4 bits for the version field and 2 bits for the variant field), leaving 122 bits of randomness. That is well above the 80-bit threshold, which is why UUID v4 is widely used for unguessable identifiers, idempotency keys and tokens. This tool produces RFC 4122-compliant v4 UUIDs using crypto.randomUUID() when the browser supports it, falling back to crypto.getRandomValues() with the correct version and variant bits set.

Why offer an 'Exclude ambiguous characters' option?

Ambiguous glyphs like 0/O and 1/l/I are easy to misread when a credential is printed, written by hand, dictated over the phone, or read off a screen in a poor font — leading to failed logins and support tickets. Excluding them improves transcription accuracy for human-handled secrets (Wi‑Fi keys, voucher codes, initial passwords). The trade-off is a slightly smaller alphabet and therefore slightly lower entropy per character; the entropy readout reflects the reduced pool automatically, so you can lengthen the value to compensate if needed.

What does 'No repeating characters' do, and what is the length limit?

When enabled, every character in the output is unique. Because a string with no repeats cannot be longer than its alphabet, the requested length is automatically clamped to the alphabet size — for example you can get at most 10 unique characters from the digits 0–9, or about 16 unique symbols from a 16-character pool. The tool builds the value from a securely shuffled copy of the alphabet (Fisher–Yates with the CSPRNG), so the result is unbiased and contains no duplicates. Note that forbidding repeats slightly reduces entropy compared with allowing them, so for maximum strength on long secrets leave it off.