Base64 Encoder / Decoder

Base64 Encoding Explained

What is Base64 and why is it used?

Base64 is a way of representing arbitrary binary data using only 64 printable ASCII characters. It exists because many channels that carry data were designed for text: e-mail (MIME), XML and JSON documents, HTTP headers (Basic authentication), URLs, cookies, configuration files, source code… None of them can safely carry raw bytes such as 0x00 or 0xFF, but all of them can carry letters and digits. Base64 lets you embed an image in a CSS file, attach a PDF to an e-mail or store a cryptographic key in a JSON document without any byte being mangled by line-ending conversions, character-set translations or control-character filtering. It is specified in RFC 4648.

Base64 is not encryption: it hides nothing and anyone can decode it instantly. It is an encoding, exactly like hexadecimal, only more compact.

How does it work?

The input is processed three bytes at a time. Three bytes are 24 bits; those 24 bits are split into four groups of 6 bits, and each 6-bit value (0–63) is looked up in the alphabet below. So every 3 input bytes become 4 output characters.

Text:      H        i        !
Bytes:     01001000 01101001 00100001
6-bit:     010010 000110 100100 100001
Values:    18     6      36     33
Base64:    S      G      k      h        → "SGkh"

Decoding is the reverse operation: each character is turned back into its 6-bit value, the bits are concatenated and cut into bytes.

The Base64 alphabet

The pad character = is not part of the alphabet; it only marks the end of the data.

Padding

When the input length is not a multiple of 3, the last group is incomplete. One remaining byte produces two characters followed by ==; two remaining bytes produce three characters followed by a single =. The padding makes the encoded length always a multiple of 4, which lets decoders work on fixed-size blocks. Many modern protocols (JWT, HTTP/2 headers, base64url in general) omit padding because the length of the data makes it redundant; this tool accepts both padded and unpadded input.

The URL-safe variant (base64url)

The standard alphabet contains + and /, which are reserved characters in URLs (and / is a path separator on file systems). RFC 4648 §5 defines a second alphabet where they are replaced by - and _, and where padding is usually dropped. It is used by JSON Web Tokens, by Google and Amazon APIs, by YouTube video IDs and anywhere a Base64 string ends up inside a URL or a file name. Tick "URL-safe alphabet" to produce it; the decoder recognises both alphabets automatically.

Size overhead and line breaks

Because 3 bytes become 4 characters, Base64 output is about 33% larger than the input (4/3 ratio, plus up to 2 padding characters). Adding MIME line breaks every 76 characters costs another 2.6%. This overhead is why large binary attachments make e-mails noticeably bigger, and why embedding big images as data URIs in a web page is usually a bad idea beyond a few kilobytes.

MIME (RFC 2045) requires encoded lines of at most 76 characters separated by CRLF; PEM certificates use 64-character lines. Decoders ignore whitespace, so line breaks never change the decoded result.

Data URIs

A data URI embeds a resource directly in a document instead of linking to it: data:[<mime type>][;base64],<data>. The "Encode as data URI" button builds one from your text or your uploaded file, for example:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...">
background: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...");
<a href="data:text/plain;charset=utf-8;base64,SGVsbG8sIFdvcmxkIQ==" download="hello.txt">

Common uses

• E-mail attachments (MIME) and embedded images in HTML e-mails.
• HTTP Basic authentication: Authorization: Basic base64(user:password).
• JSON Web Tokens: header, payload and signature are base64url without padding.
• Certificates and keys in PEM format (-----BEGIN CERTIFICATE-----).
• Binary data in JSON/XML APIs, e.g. file uploads or protobuf bytes fields.
• Data URIs in CSS and HTML to avoid extra HTTP requests for tiny assets.

Everything on this page runs in your browser. Uploaded files are never sent to a server; "Decode and download" sniffs the magic bytes of the decoded data (PNG, JPEG, PDF, ZIP, MP3…) to give the file a sensible extension.