About the Base64 Encoder & Decoder
This Base64 encoder converts text into standard Base64 and decodes Base64 back into readable text. A URL-safe option swaps the plus and slash characters for hyphen and underscore and drops the padding, producing the base64url variant used in JSON Web Tokens, cookies and filenames. When encoding, a size panel shows the input length, the output length and the percentage overhead so you can judge whether inlining a value is worthwhile. Both directions run in your browser with nothing transmitted, though it is worth remembering that Base64 is an encoding rather than any form of protection.
How to use the Base64 Encoder & Decoder
- 1
Paste your text or an existing Base64 string into the 'Text or Base64' box.
- 2
Set 'Action' to either 'Encode to Base64' or 'Decode from Base64'.
- 3
Tick 'URL-safe output' when encoding a value that will sit in a URL, a cookie or a filename.
- 4
Copy the result, or download the encoded output as encoded.txt.
What people use it for
Inspecting JSON Web Tokens
A JWT is three base64url segments separated by full stops. Pasting the middle segment with URL-safe decoding reveals the claims, which is the quickest way to check an expiry or an audience during debugging.
Building HTTP Basic Auth headers
Basic authentication sends username:password as Base64 after the word Basic. Encoding the pair here produces the exact header value for a curl command or an API client.
Embedding small assets as data URIs
An SVG icon or a tiny PNG can be inlined in CSS as a data URI to save a request. The overhead figure tells you how much larger the inlined version will be than the original file.
Passing text safely through legacy channels
Email headers, some XML fields and older message queues mangle non-ASCII bytes. Base64 reduces arbitrary text to a safe 64-character alphabet that survives the trip.
How Base64 works and why padding exists
Base64 is specified in RFC 4648. It takes three bytes of input, 24 bits in total, and regroups them into four six-bit values, each of which indexes into an alphabet of A to Z, a to z, 0 to 9, plus and slash. Four output characters for every three input bytes is where the familiar 33% size increase comes from. The complication is that input is rarely a multiple of three bytes. When one byte remains, it supplies eight bits which are padded to twelve to make two output characters; when two bytes remain, sixteen bits become eighteen, giving three characters. In both cases equals signs are appended to bring the final group up to four characters, so a Base64 string is always a multiple of four in length and ends with zero, one or two equals signs — never three. The padding carries no data of its own. It exists so that decoders reading a stream of concatenated Base64 values know where each one ends, which is why it is required in some contexts and optional in others. Since text must become bytes before any of this happens, the input here is encoded as UTF-8 first, so non-ASCII characters expand before they are encoded.
Base64url, and why Base64 is not security
Standard Base64 uses plus and slash as its final two alphabet characters, and both cause trouble in a URL: a slash reads as a path separator, and a plus is interpreted as a space by form decoding. RFC 4648 section 5 therefore defines base64url, which substitutes hyphen for plus and underscore for slash and permits the padding to be omitted, since an equals sign also needs escaping in a query string. That is the variant JWTs use, and it is what the URL-safe option here produces. A decoder that expects standard Base64 will reject a base64url string, which is a common cause of mysterious token failures. The more important point is what Base64 is not. It is a reversible encoding with no key, so anyone can decode it instantly — it provides exactly zero confidentiality. Storing a password Base64-encoded in a config file, or treating an encoded value as a secret token, is a real and frequently exploited mistake. Base64 exists to make binary data survive text-only channels, nothing more. If you need secrecy, encrypt the data and then, if the channel requires it, Base64-encode the ciphertext.
Tips
- A valid Base64 string is always a multiple of four characters long once padding is included — an odd length means it was truncated.
- Split a JWT on its full stops and decode each part separately; decoding the whole token at once will fail.
- Expect roughly a third more characters after encoding, so a value near a field's size limit may no longer fit.