Base64 to Text

When you do not know what you are holding

The other pages in this section assume you already know the payload is JSON, XML or YAML. Often you do not. Someone forwards a string from a log line, a header, a database column or a support ticket, and the first question is simply what is this. That is what this page is for — decode it, look at it, and decide what to do next.

Paste and read. Nothing is sent anywhere, which is worth stating because the strings people investigate this way are frequently credentials, session tokens or customer data pulled from somewhere they should not stay.

Base64 comes in more than one dialect, and the browser's built-in atob() only speaks one of them. Anything from a URL or a token uses the URL-safe alphabet, with - and _ in place of + and /, and usually with the trailing = removed. Terminal output from openssl base64 or kubectl arrives wrapped across lines. A string copied out of a stylesheet has a data: prefix stuck to the front. All four are handled here, and whatever had to be changed is listed under the output.

The other thing this page does is tell you when the answer is "that is not text at all". A decoded PNG or gzip archive rendered as characters is a screenful of noise that looks like a broken tool. Instead you get the byte count and, where the leading bytes are recognisable, what kind of file it is.

Working out what a blob is

1. Paste the string – In whatever state you found it — wrapped, unpadded, URL-safe, with a data: prefix. If it came out of a browser address bar, run it through decodeURIComponent() first so the %3D sequences become real characters.
2. Read the text and the counts – Bytes, characters and lines appear beside the title. Bytes and characters differing tells you the content is not plain ASCII, which is sometimes the answer on its own.
3. Follow the hint if one appears – When the decoded text looks like JSON, XML or YAML, a note points at the page that will format and check it properly. A certificate body is flagged as such too.
4. If it is binary, read what it says – A message naming a PNG, a PDF or a gzip archive means the Base64 was perfectly valid and the content simply is not text. That is an answer, and usually a useful one.

A JWT is three Base64 segments separated by dots, and only the first two are meant to be read. Decode the second for the claims and the first for the algorithm. The third is a signature over raw bytes and will always come back as "not text" — that is correct behaviour, not a failure, and it is the single most common thing people mistake for a broken decoder.

The Basic auth header, all the way down

A good illustration of what Base64 is and is not. An HTTP Basic credential looks scrambled in a header, and people treat it as though it were protected. Decode it and you get the username, a colon, and the password in plain view — no key, no hash, nothing reversible only by the server.

# the header as it goes over the wire
Authorization: Basic cm9zYWxpbmQ6ZnJhbmtsaW4=

# decode that value on its own…

rosalind:franklin

# username, colon, password.
# no hashing, no key, no salt —
# which is why Basic auth over
# plain HTTP hands out credentials
# to anyone watching the network.

What people use it for

Identifying a mystery string

A column called payload, a header nobody documented, a query parameter that appeared after a vendor integration. Decoding is the cheapest possible first step, and it either gives you the answer or tells you the content is binary, which narrows things considerably.

Reading a JWT header or payload

Split the token on the dots and decode the first two segments. The header names the signing algorithm, the payload carries the claims. If you know it is JSON, Base64 to JSON indents it for you; this page is for when you are still working out which segment is which.

Checking a certificate or key file

PEM is Base64 with header and footer lines around it. Stripping the -----BEGIN CERTIFICATE----- markers and decoding the body gives you DER — binary, not text — which this page will identify rather than print as noise. Useful for confirming a file is what its extension claims.

Explaining to someone why Basic auth needs TLS

Decoding a credential in front of a colleague makes the point far better than describing it. The example above takes about four seconds to reproduce and tends to end the discussion.

What it handles

• Every dialect. Standard and URL-safe alphabets, padded or not, wrapped across lines, with or without a data: prefix — all decoded, with a note saying what was adjusted.
• Correct UTF-8. Accented characters, CJK text and emoji come back as themselves rather than as replacement characters.
• Binary is identified. PNG, JPEG, GIF, PDF, gzip, ZIP and DER certificates are recognised from their leading bytes and reported by name with a size.
• Format hints. When the text is JSON, XML or YAML, you are pointed at the page that will format and validate it.
• Byte, character and line counts. Bytes and characters differing is itself information about what you are looking at.
• Nothing is transmitted. Tokens and credentials stay in this tab.

Questions that come up

Is Base64 encryption?

No. There is no key and no secret — the transformation is public and reversible by anyone, which is exactly what you just did. It exists so that arbitrary bytes can travel through a channel that only accepts text. Anything relying on it for confidentiality is not protected, and treating it as though it were is how credentials end up in commit history.

Why does atob() reject a string that works here?

Two reasons, usually together. It does not accept the URL-safe alphabet, so a JWT segment fails on its first -. And it is picky about padding — a string whose length is not a multiple of four is rejected outright rather than repaired. There is a matching trap on the way out: btoa() silently encodes non-ASCII as Latin-1 instead of UTF-8, so café becomes Y2Fm6Q== where it should be Y2Fmw6k=. MDN documents the whole business.

My decode failed with "the length is impossible".

Base64 turns three bytes into four characters, so a valid string is never exactly one character past a multiple of four. That length can only happen if a character was lost — a wrapped line missed in a copy, or a truncating field. Go back to the source and take the whole thing.

It says the bytes are not text. Did something go wrong?

Nothing went wrong. The Base64 decoded perfectly; the result simply is not characters. Images, archives, DER certificates, encrypted payloads and JWT signatures all look like this. Where the leading bytes are a known file signature the page names the format, which usually tells you what to do next.

Can I decode a whole file?

Upload works for a text file containing an encoded string, and there is no practical size limit for text. What this page will not do is reconstruct a binary file for download — if you have a Base64'd image or archive, decoding it is a job for base64 -d at a terminal, which writes real bytes to disk.

Where do I go if it turns out to be structured?

Base64 to JSON indents and validates JSON and keeps long identifiers exact. Base64 to XML checks well-formedness and inflates compressed SAML. Base64 to YAML parses config and preserves comments. This page will point you at whichever fits.

Related tools

Worth reading

• RFC 4648 — Base16, Base32 and Base64 – Both alphabets, the padding rules, and why decoders disagree about them
• RFC 7617 — the Basic HTTP authentication scheme – States outright that Base64 provides no confidentiality and the scheme needs a secure channel
• MDN: Base64 – The Unicode problem with btoa and atob, and the way round it