Generate random Base64 strings from a chosen number of random bytes, with standard or URL-safe alphabets and optional padding. Because Base64 encodes three bytes as four characters, the tool sizes the request in bytes so the entropy is stated honestly.
Settings
Recent results
Generated locally in your browser β your settings and results never leave this page.
What Base64 solves
Plenty of systems were built to carry text and behave unpredictably when handed arbitrary bytes. Email bodies, JSON string fields, URLs, XML documents, HTTP headers and configuration files all assume printable characters. A raw byte sequence pushed through any of them risks being mangled by a control character, an encoding conversion or a null byte.
Base64 sidesteps the problem by re-expressing the data in a small alphabet that every system agrees on: the letters, the digits, and two punctuation marks. The data survives the journey and can be reconstructed exactly at the other end. The cost is size β four characters for every three bytes, roughly a third larger than the original.
The arithmetic behind the length
Base64 processes three bytes at a time. Three bytes is 24 bits, which divides evenly into four groups of six, and six bits index a 64-character alphabet. When the input is not a multiple of three the final group is incomplete, and padding characters record how many bytes it actually held so the decoder can reproduce the original exactly.
This is why the tool asks for bytes. If you request 32 bytes you get 256 bits of entropy, and the character count follows from the encoding rather than the other way round. Asking for a character count first would produce a value whose strength depended on a detail most people would not think to check.
Encoding is not encryption
It is worth stating plainly because the mistake appears in real systems: Base64 provides no confidentiality. There is no key. Anyone who recognises the format can decode it in a second, and every programming language ships a decoder. A password stored Base64-encoded is a password stored in plain text with an extra step.
The confusion is understandable β encoded text looks scrambled β but the appearance of randomness is not a security property. If data needs protecting, it needs encryption, and the encoded form is what you would apply afterwards to make the ciphertext safe to transport.
Choosing an alphabet
The standard alphabet ends with plus and slash, which are fine in an email attachment and problematic in a URL. Placed in a path, a slash reads as a separator. Placed in a query string, a plus is commonly interpreted as an encoded space. Either can corrupt the value silently, which is the worst kind of failure because everything appears to work until a particular random value happens to contain the wrong character.
The URL-safe variant replaces those two characters with hyphen and underscore. Both are inert in URLs and filenames. If a generated value will ever appear in a link, a path, or a filename, use it β the alternative is a bug that surfaces unpredictably.
Padding and when to drop it
Padding exists so a decoder knows the length of a partial final group. Many formats omit it anyway, because the length is already known from context. JSON Web Tokens use unpadded URL-safe Base64 in all three of their segments, and trailing equals signs there are simply wrong.
Dropping padding removes at most two characters and changes nothing about the data. Keep it when your decoder is strict; drop it when the format you are targeting says to.
Privacy
Values are generated in your browser from its cryptographic random source. Nothing is transmitted, stored, logged or written into the URL.
How to use the Random Base64 Generator
- Set how many random bytes should go into each value. The character length follows from that.
- Switch to the URL-safe alphabet if the value will appear in a link or a filename.
- Turn padding off if your target rejects trailing equals signs.
- Generate and copy.
Frequently asked questions
What is Base64?
A way of writing binary data using only 64 printable characters, so it can travel through systems that expect text. It takes three bytes at a time and rewrites them as four characters, which is why encoded output is about a third longer than the data it carries.
Why does this tool ask for bytes rather than characters?
Because bytes are what carry the entropy. Asking for 32 characters would be ambiguous β the strength depends on the alphabet. Asking for 32 bytes means you get 256 bits regardless of which format you display it in, so the security claim stays honest.
What is the URL-safe alphabet?
Standard Base64 uses plus and slash as its last two characters, and both have meaning in URLs β slash separates path segments, plus can be read as a space in query strings. The URL-safe variant substitutes hyphen and underscore, which pass through URLs and filenames unchanged.
What are the equals signs at the end?
Padding. Because Base64 works in groups of three bytes, input that is not a multiple of three leaves a partial group, and the padding marks how many bytes were in it. Some formats β JSON Web Tokens among them β omit the padding because the length can be inferred, which is why the tool lets you turn it off.
Is Base64 a form of encryption?
No, and this is a common and consequential misunderstanding. Base64 is an encoding: it is fully reversible by anyone, with no key involved. It changes how data is written, not who can read it. Base64-encoding a secret provides no protection whatsoever.
Can I use these values as tokens?
Yes β a value generated from 32 random bytes is a perfectly good 256-bit token. If you want a prefix, a choice of formats, or an explicit entropy readout, the dedicated token generator is built for that job and uses the same underlying randomness.
Why is the output length not exactly what I expect?
Base64 length is driven by the byte count rounded up to the next group of three. Sixteen bytes is not divisible by three, so it encodes to 24 characters including padding rather than a round number. Turning padding off shortens the result without changing the data.
