Base64 Encoder/Decoder

Encode and decode Base64, and eight other formats at the same time

Type or paste into the input above and the result appears immediately — there is no submit step. In encode mode you get every output format at once: standard Base64, URL–safe Base64, hexadecimal, binary, ASCII decimal, percent–encoding, Base32 and Unicode escapes, each with its own copy button. In decode mode the tool inspects the input, decides which of those formats it is looking at, and decodes it back to text. Everything runs in your browser; nothing you paste is uploaded, logged or stored.

Two mode switches sit above the input. Encode/Decode chooses direction. Encoding Formats / Escape Sequences chooses which family of conversions you are working in — the first is Base64 and its neighbours, the second is \x, \u, %, HTML entity and octal escapes, with a per–character breakdown table. In encode mode a Standard / URL–Safe toggle sets which variant lands in the main output box, though both are always present in the formats panel below.

Base64 is encoding, not encryption

This is the single most important thing on the page, and it is the reason Base64 appears in so many security incidents. Base64 has no key. It is a public, fully documented, deterministic mapping from bytes to a 64–character alphabet, defined in RFC 4648. Anyone who sees cGFzc3dvcmQxMjM= reverses it in one step — including in this tool, in one line of Python, or by eye once you have seen enough of it. There is no attacker capability required beyond recognising the format.

What Base64 is for is transport. It exists because a great many systems — email bodies, HTTP headers, JSON strings, XML documents, URLs, log lines, YAML config — are defined over text, not arbitrary bytes. Feed raw binary through them and you lose data to newline translation, character–set conversion, or a parser that treats byte 0x00 as a terminator. Base64 restricts output to A–Z, a–z, 0–9, + and /, all of which survive that journey intact. It answers “how do I move bytes through a text channel”. It does not answer “how do I keep this secret”.

The practical consequence: a Base64–encoded credential in a config file, a Kubernetes Secret, an environment variable or a log line is a plaintext credential. Kubernetes Secrets in particular are Base64–encoded, not encrypted, at rest by default, which is a routinely misunderstood point. If the value must stay confidential, it needs a real cipher or a secrets manager, and Base64 changes nothing about its exposure.

How Base64 works: six bits at a time

The alphabet has 64 symbols, and 64 is 2⁶, so each output character carries exactly six bits. Input bytes carry eight. The least common multiple of 6 and 8 is 24, so the algorithm works in 24–bit groups: take three input bytes, concatenate their bits into a 24–bit block, split that block into four six–bit indices, and look each index up in the alphabet.

Take the three bytes of Man: 01001101 01100001 01101110. Regroup those 24 bits into fours of six: 010011 010110 000101 101110, which are 19, 22, 5 and 46. Index 19 is T, 22 is W, 5 is F, and 46 is u — so Man encodes to TWFu. Three bytes in, four characters out.

That four–for–three ratio is where the size overhead comes from. Four characters occupy four bytes of a text channel to carry three bytes of payload, so encoded output is 4/3 the size of the input: a 33% increase, before any line breaks are added. This is why you do not Base64 large binaries into JSON payloads if you can avoid it, and why a multipart upload beats an inline data URI for anything sizeable.

Padding, and what a stray = tells you

Input is rarely a clean multiple of three bytes. When one or two bytes are left over, the encoder pads the final bit group with zeros and then pads the output with = so the total character count is a multiple of four:

Padding is therefore a length signal, never data. It appears only at the very end of a string, and never as one = in the middle. Two rules follow that are useful when you are staring at a suspect string: a well–formed padded Base64 string always has a length divisible by four, and = appearing anywhere but the tail means you are looking at two concatenated strings, a truncated copy, or something that is not Base64 at all.

RFC 4648 also permits padding to be omitted where the length is known from context, which is what the URL–safe variant normally does. Decoders differ on whether they accept unpadded input; this tool re–adds padding before decoding, so both forms work here even when a stricter decoder elsewhere rejects one of them.

RFC 4648 standard Base64 versus base64url

RFC 4648 defines several encodings — Base16 (hex), Base32, and Base64 — along with a URL–safe alternative alphabet for the last two. The Base64 variants differ in exactly two of the sixty–four symbols plus their treatment of padding.

Both alphabets appear in the formats panel every time you encode, so you can take whichever the destination needs. To convert an existing string between them by hand: replace - with + and _ with /, then append = until the length is a multiple of four to get standard Base64, and reverse the substitutions and strip the padding to go the other way.

One more variant worth knowing: MIME (RFC 2045) mandates a line break every 76 characters. That is why Base64 pasted out of an email source or a PEM certificate arrives as a block of wrapped lines. Decoders are expected to ignore the line breaks; the ones that do not will report an invalid character. The tool trims surrounding whitespace on the input, which handles the usual trailing–newline case from a copy–paste.

Decoding a Basic auth header

HTTP Basic authentication (RFC 7617) is one of the most common reasons to reach for a Base64 decoder. The credential is constructed by joining the user ID and the password with a single colon and Base64–encoding the resulting UTF–8 bytes, then prefixing the scheme name:

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Paste just the encoded part — not the word Basic, and not the header name — into the decoder and you get aladdin:opensesame back: user ID before the colon, password after. Two things about that are worth stating plainly. First, the password is recoverable by anyone who captures the header, which is why Basic auth is only acceptable over TLS. Second, the user ID cannot contain a colon, because the first colon is the separator; the password can, and everything after the first colon belongs to it, so do not split on the last one.

If the decoded output contains no colon at all, you did not have a Basic credential — most likely you pasted a Bearer token, which is a different scheme entirely and is usually a JWT. Send those to the JWT decoder, which splits the three segments and reads the claims rather than treating the whole thing as one blob.

Files, images and data URIs

In encode mode you can drop a file onto the upload area, or click to browse, up to 10 MB. The file is read in your browser and its bytes are Base64–encoded — the file is never uploaded anywhere. Image files also get a preview so you can confirm you encoded the right one. The URL–safe toggle applies to file output too.

The usual destination for that output is a data URI (RFC 2397), which inlines a resource directly into markup or CSS instead of referencing a separate file:

<img src="data:image/png;base64,iVBORw0KGgo...">

The shape is data:, then the MIME type, then ;base64,, then the encoded bytes with no line breaks and no whitespace. Take the MIME type from the actual file type — image/png, image/svg+xml, font/woff2 — because browsers will not sniff it for you here. Remember the 33% overhead: inlining trades an HTTP request for a document that is a third larger than the asset and cannot be cached separately from the page, which is a good trade for a small icon and a bad one for a photograph. Note too that a data URI is not the whole story for Content Security Policy — a strict policy may block data: sources outright.

Decode auto–detection, and when it guesses wrong

In decode mode the tool does not ask you what format the input is; it tests the string against a series of patterns and takes the first that matches, in this order: Unicode escapes, percent–encoding, ASCII decimal, Base32, binary, hexadecimal, then Base64. The detected format is displayed, so you can always see which branch it took. That ordering is what causes the occasional surprising result, and it is worth knowing the three cases:

• Base64 that contains only letters is read as Base32. The Base32 alphabet is A–Z and 2–7, and the check is case–insensitive, so a Base64 string of eight or more characters with no 0, 1, 8, 9, + or / in it matches Base32 first. dGVzdA== is the canonical example — it is Base64 for test, but it decodes here as Base32 and produces unreadable bytes. If your output is garbage and the detected format says Base32, that is what happened.
• Base64 made only of hex characters is read as hexadecimal. A string like abcdef12 is valid Base64 and valid hex; the hex branch is checked first, so you get the hex interpretation.
• Short strings pass through unchanged. Base64 detection requires more than four characters, so a four–character token such as YWJj is treated as plain text and returned as–is.

The workaround in all three cases is the same: switch to encode mode and use the formats panel, which shows every interpretation side by side, or decode the value with an explicit–format tool. Ambiguity here is inherent to the input rather than a failure of detection — those strings genuinely are valid in more than one encoding, and nothing in the string itself says which was intended.

There is one recovery feature for damaged input. Base64 is case–sensitive, so a string that has been lowercased somewhere in a pipeline — by a case–insensitive database column, a logging system or a shell — has genuinely lost information. When the input is entirely lowercase, the tool tries to reconstruct the original casing by scoring candidate decodings four characters at a time for how much they look like readable text or JSON, and reports a confidence figure with the result. Treat a low–confidence recovery as a guess and go back for the original string.

Reading the other output formats

Every encode also produces hexadecimal, binary, ASCII decimal, percent–encoding, Base32 and Unicode escapes. The Base64 and Base64–URL outputs are UTF–8 correct for any input, including emoji and accented characters. The hexadecimal, binary and ASCII decimal columns list one value per character rather than per UTF–8 byte, so they line up exactly with the bytes for ASCII input but show code–unit values above U+007F. When you specifically need the UTF–8 byte sequence of a non–ASCII string, use the Escape Sequences tab instead: its character breakdown table gives the code point, the hex and decimal values, and the actual UTF–8 bytes for every character, and its \x, percent and octal outputs are all built from real UTF–8 bytes.

That second tab is also where mixed or unfamiliar escaping gets untangled. It encodes text to \xHH, \uHHHH, ES6 \u{...}, %HH, &#x...;, &#...; and octal escapes simultaneously, and in decode mode it detects which of those is present — reporting “mixed” when several are — and unwinds them in an order that handles nested and combined escaping, which is the usual state of a string pulled out of an obfuscated payload or a doubly–encoded log entry.

Finishing the job

Output can be copied per format, or downloaded as encoded.txt or decoded.txt. The share button produces a link that reproduces the current mode, tab, variant and input, provided the input is under 500 characters — convenient for handing a colleague the exact case you are looking at, and a reason not to share links containing anything sensitive. When the result is a step rather than an answer, the chain buttons pass it straight into the next tool: format it as JSON, URL–encode or HTML–encode it, identify a cipher, try an XOR, or analyse a multi–layer encoding chain.

Use something else when the input is structured rather than raw: a JWT belongs in a JWT decoder, and if the string is not an encoding at all but a ciphertext, a cipher identifier will place it faster than guessing here. And if you are reaching for Base64 to protect a value rather than to transport one, stop — that is the job of encryption, and no amount of encoding will do it.