Generator losowych bajtów

What the random bytes generator does

This tool produces cryptographically secure random bytes — the raw material behind almost every secret in software — and shows them in whichever representation you need. Ask for anywhere from 1 to 4096 bytes and choose an output format: lowercase hex, uppercase hex, space-separated hex, Base64, a comma-separated decimal array, or a binary string of ones and zeros. You reach for it when you need genuine randomness rather than a memorable value: generating an encryption key, an initialisation vector or nonce, a salt for password hashing, a CSRF or session token, an API key, or a signing secret.

How it works and why the source matters

The tool fills a byte array with the browser's crypto.getRandomValues, which draws from the operating system's cryptographically secure random generator. Each byte is a uniformly distributed value from 0 to 255, so n bytes carry n × 8 bits of entropy — provided the source is a real CSPRNG, which this one is. That is the crucial difference from Math.random: that function is fast and perfectly fine for shuffling a deck or picking a colour, but it is predictable and must never be used to generate keys or tokens. The output format you pick changes only how the same bytes are written down, not how much randomness they hold: n bytes become 2n hexadecimal characters, or roughly a third more characters in Base64, or eight digits per byte in binary. Encoding never adds entropy; it just makes the bytes easier to paste into a config file, an HTTP header, or source code.

Choosing a size and a format

How many bytes you need depends on the job, but a useful rule of thumb covers most cases:

• 16 bytes (128 bits) is the practical minimum for a secret such as an API token, a session identifier, or a salt.
• 32 bytes (256 bits) is the standard size for a strong symmetric key, for example an AES-256 or a ChaCha20 key, and for an HMAC signing secret.
• 12 bytes is the usual length for an AES-GCM nonce — and a nonce must never be reused with the same key, or the encryption's confidentiality and integrity guarantees fall apart.

The format buttons then decide how those bytes are written down. Reach for hex when you want a compact, unambiguous value to paste into a config file or environment variable; Base64 when you need something even shorter for an HTTP header or a token; the decimal array when you are pasting straight into source code as a byte list; and binary when you want to see the individual bits, which is handy for teaching or for reasoning about a bitmask.

Gotchas and a privacy note

A handful of pitfalls trip people up. Hex and Base64 are only representations, so a longer-looking string does not mean a stronger key — the entropy is set by the byte count alone. Salts and initialisation vectors must be unique but need not be secret, whereas keys must be both unique and kept secret, so do not treat them interchangeably. If you copy a value to the clipboard, remember that other applications can read it, so clear it once you have pasted. And while generating a key in the browser is perfectly sound for many purposes, for a long-lived production secret it is often better to generate it directly on the machine that will use it, so the key never travels at all.

Everything here is generated 100% locally in your browser from its own cryptographic random source — no bytes are ever sent to, stored on, or logged by any server, which is precisely what you want when the output is a real secret. You can confirm it by going offline and watching the generator keep working. When you are ready to put these values to work programmatically, the s4m API documentation shows where keys and tokens belong.