Pixitools

Search Pixitools

Search tools, utilities and conversion pages

8 min read

Base64 Explained: How to Encode and Decode Text and Files

Base64 turns up wherever binary data has to travel through something that only speaks text: JSON payloads, config fields, email attachments, inline images, URL-safe tokens. It is a transport encoding — reversible by anyone, with no key involved — and the small set of mistakes around it is mostly about treating encoded bytes as text. This guide covers what the transformation actually does, how to encode text and files, how to decode a payload back into a real file, and how to read the errors when it goes wrong.

What the transformation actually does

Base64 re-expresses bytes using 64 printable characters — A–Z, a–z, 0–9, plus + and / — so the result survives channels that mangle anything else: charset conversions, line-ending rewrites, control characters, CSV tools and clipboard round trips. Every three bytes become four characters, which is where the familiar one-third overhead comes from, and the final group is padded with = so the length always lands on a multiple of four.

InputBase64Why the length changes
PixUGl43 bytes → exactly 4 characters, no padding
PixitoolsUGl4aXRvb2xz9 bytes → 12 characters, still exact
Hello Pixitools!SGVsbG8gUGl4aXRvb2xzIQ==16 bytes → 24 characters, with = padding
café ☕Y2Fmw6kg4piV9 bytes of UTF-8 for 6 visible characters

Encoded is not encrypted

This is the misunderstanding worth clearing up first. Base64 has no key and no secret: anyone holding the string can decode it with a standard library, a command-line tool or a decoder page. It does not hide the content, does not hide the length, and does not slow an attacker down. It exists to move bytes through text, nothing more.

Encoding text

Text is UTF-8 encoded first and then re-expressed in Base64, which is why accented letters and emoji survive the round trip: `café ☕` is nine bytes of UTF-8, not six characters, and the encoder works on those bytes. The Base64 Encoder does exactly that and gives you the result in the shape the destination expects.

  • Standard Base64 with = padding — what most APIs, config files and documentation expect.
  • URL-safe Base64 — + and / become - and _, and the padding is dropped, which is what URLs, filenames and JWT segments need.
  • A data URI — the complete `data:text/plain;base64,…` string, ready to drop into HTML, CSS or a JSON field.
  • Wrapped at 76 characters — the MIME/PEM line layout some parsers and config loaders expect; the decoder ignores the line breaks on the way back.

Because the input is text, the output updates as you type: copy the form you need, or download it as a .txt file when the string is too long to handle comfortably in a clipboard.

Encoding a file

Switching to the file tab reads the file's exact bytes — never through a text round trip — and keeps its MIME type, so the data URI is valid and the payload decodes back to the identical file. Text, images, PDFs, archives, fonts: anything you can select. The panel shows the file name, size and type, and both the copy buttons and the download carry the complete payload — only the on-screen preview is capped for very large files.

Decoding text, data URLs and files

The Base64 Decoder accepts a raw payload or a whole data URI, and is deliberately forgiving about the things that differ between sources: whitespace and line breaks are ignored, so Base64 lifted out of an email, a PEM block or a wrapped config file works as-is; URL-safe characters are converted back automatically; and missing padding is restored, because unpadded payloads are normal in URLs and tokens.

  • Decoded text is shown when the bytes really are valid UTF-8, with its size in bytes.
  • Binary payloads are never rendered as text — the decoder keeps the raw bytes for download, reports the detected type and shows the first few bytes in hex.
  • A payload saved to a file can be loaded directly (.txt, .base64, .b64, .pem or .json, up to 10 MB) instead of pasted into the box.

Why the file type matters, and how it is decided

A data URI carries its type in the header, so `data:image/png;base64,…` decodes to a PNG and downloads with a sensible name. Raw Base64 has no such header, so a decoder has to work the type out. This one reads the file signature in the decoded bytes — PNG, JPEG, GIF, WebP, AVIF, BMP, ICO, PDF, ZIP, GZIP, MP3, MP4, and SVG or XML text — and treats anything that decodes cleanly to UTF-8 as plain text rather than offering a meaningless .bin download.

That is the difference between getting `decoded.png` and getting a generic file that no application will open, and why a payload whose type cannot be recognised still comes back as usable bytes named `decoded.bin` instead of being thrown away.

Errors, and what they actually mean

Almost every failure is the payload having been altered rather than the decoder being wrong, and the messages say which alteration it was.

What you seeWhat happenedWhat to do
A character is not valid Base64The string picked up something outside the alphabet — a URL-encoded value, a quote from the JSON it was embedded in, or an ellipsis from a truncated UICheck the source; a percent-encoded data URI is not Base64
The length cannot come from valid Base64Characters are missing, so the length is one past a multiple of fourRe-copy the whole payload, including the final characters
Padding may only appear at the endTwo payloads were concatenated, or a line was cut mid-stringFind the join and split it back into separate payloads
A data URI that is not base64-encodedThe URI uses percent-encoding, which is a different schemeNothing to decode — that content is already plain text
Binary, not UTF-8 textThe bytes are a real file: an image, a PDF, an archive, a fontDownload it instead of copying the text view

One more failure mode worth naming: text wrapped around a Base64 string is not Base64. Pasting a `data:` URL, a header line or an explanatory sentence in front of the payload will be reported as an invalid character — trim to the actual payload.

Why binary data has to stay binary

The classic corruption story: Base64 is decoded into a string, the string is copied through a text editor, and the file that comes out will not open. Text handling in browsers and editors applies UTF-8 decoding, line-ending normalisation and character substitution, and each of those changes bytes. That is the difference here — the decode result is a byte array handed straight to the download, so the file you save is the file that was encoded. When a payload is binary, the hex preview and the download button are the only faithful views of it.

Where Base64 fits, and where it does not

Reach for it when the channel is text and the payload is small or unavoidably binary:

  • Small inline images, icons and fonts in HTML or CSS, where saving a request is worth more than the one-third size increase.
  • Binary fields inside JSON APIs, where a text body is the contract.
  • Email attachments and MIME parts — the 76-character wrapping exists for exactly this.
  • URL-safe tokens with the URL-safe alphabet and no padding.
  • Single-file exports, where one self-contained document beats a folder of assets.

And leave it out when:

  • The payload is large — a separate file compresses better, caches independently and can be streamed.
  • You want confidentiality, integrity or authentication. Those are encryption, signatures and hashing.
  • You want a shorter identifier — encoding only ever makes data longer.
  • You are encoding a URL's parameters. That is percent-encoding, which is what the URL Encoder/Decoder does; Base64 and URL encoding solve different problems.

Base64 for images specifically — data URIs in HTML and CSS, and when embedding beats linking — is covered in What Is Base64 Image Encoding?, with the two image walkthroughs in How to Convert an Image to Base64 and How to Convert Base64 Back to an Image.

Try it with these tools

Every tool mentioned in this article runs entirely in your browser — see privacy for what that means.