Why is Base64 about 33% larger than the input?

Exactly 4 output characters per 3 input bytes: +33.3%, plus up to two bytes of '=' padding. On this site's 26-document sample corpus the measured median overhead was +33.5%. A 300 KB file becomes 400 KB.

Is Base64 encryption?

No. Anyone can reverse it with no key. Treat Base64 as a transport costume for bytes, the same way hex is a costume. Confidentiality needs a real cipher, not an alphabet.

What is the difference between Base64 and Base64URL?

The last two alphabet characters: +/ versus -_, and padding. The bytes are identical. JWT segments use Base64URL, which is why a raw atob() call often fails until you swap characters. See Base64 vs Base64URL.

Can I encode a file, not just text?

Yes. The Base64 tool's file mode reads an image, PDF or any file up to 50 MB in this tab and emits Base64 or a data: URL, and the reverse. Nothing is uploaded.

Why do I see '=' at the end?

Padding. Input length mod 3 is 1 or 2 leftover bytes, so the encoder emits one or two '=' to keep the output a multiple of 4 characters. Base64URL often drops them because the length is otherwise known.

What is Base64 encoding? | LocalFirstTools

Q: What is Base64 encoding?

Base64 encoding is a reversible mapping, defined in RFC 4648, that turns every three bytes of binary data into four ASCII characters from a 64-character alphabet so the bytes can travel through text-only channels. It is not encryption and it is not compression.

Computers store bytes. Email, JSON, URLs and many logs store text. Base64 is the oldest widely deployed way to drag bytes through a text channel without them being mistaken for line breaks or non-ASCII. RFC 4648 section 4 is the modern spec. The Base64 tool implements it in your browser: text or a file in, encoded or decoded bytes out, nothing uploaded.

The 4-for-3 rule

The alphabet has 64 characters, A–Z, a–z, 0–9, plus + and /. Sixty-four symbols are 6 bits each. Three input bytes are 24 bits, which split into four 6-bit indices. Four output characters for three input bytes is a 4/3 ratio: exactly +33.3% before padding. That identity is why a 3-byte input becomes 4 characters and a 300,000-byte file becomes 400,000 characters, both computed by the same base64Length helper the tool uses and published on /stats.

bytes:  M     a     n
        01001101 01100001 01101110
groups: 010011  010110  000101  101110
chars:  T       W       F       u

Leftover bytes are padded with = so the output length stays a multiple of four. One leftover byte produces two padding characters; two leftover bytes produce one. Short strings therefore sit slightly above +33.3%. Encoding every file in this site's 26-document JSON corpus produced a median overhead of +33.5% (min +33.3%, max +34.1%). The spread above 33.3% is padding, not a different algorithm.

It is encoding, not cryptography

Reversing Base64 requires no key. If a token, image or document is only Base64-wrapped, anyone who sees the wrapper can recover the bytes. JWTs look opaque because they are Base64URL, not because they are encrypted: the payload is readable after a decode. Use a cipher if the bytes are confidential. Use Base64 when a protocol refuses raw binary.

Hex is the sibling encoding that uses two characters per byte (exactly 2×). Base64 is denser (4/3×) and still ASCII. Hex is easier to eyeball; Base64 is what data URLs, PEM certificates and MIME bodies use. Convert either locally with hex or Base64.

Base64URL, JWTs and atob()

URLs and filenames treat +, / and = as special. RFC 4648 section 5 defines Base64URL: the same 6-bit mapping with - and _ in the last two alphabet slots, and padding usually omitted. JWT header and payload segments are Base64URL. That is why atob(segment) throws until you swap the alphabet and restore padding. The mechanical conversion is in Base64 vs Base64URL; the JWT Decoder does it for you.

atob(seg.replace(/-/g, "+").replace(/_/g, "/") + "==".slice(0, (4 - seg.length % 4) % 4))

data: URLs and files

A data URL is a Base64 body with a MIME type on the front: data:image/png;base64,iVBOR…. Inlining a large image that way costs the +33.3% plus the HTTP overhead of a giant HTML document, which is why production sites usually keep binaries as files. For a small icon, or for pasting an image into a JSON fixture, the file mode on this site's Base64 page reads up to 50 MB in the tab, sniffs PNG, JPEG, GIF, WebP and PDF magic bytes on the way back, and never posts the file.

Open Base64. Text mode for strings; file mode for binaries.
Toggle URL-safe if the alphabet uses - and _ (JWTs, WebAuthn, PKCE).
Wrap 76 if you need MIME line length (RFC 2045).
Decode: paste or drop. Non-UTF-8 bytes show as hex rather than mojibake.

What Base64 is not

Not compression. Output is larger, always, except for the empty input.
Not a checksum. Use SHA-256 on the hash generator.
Not a substitute for percent-encoding in a query string. URLs that must carry binary usually want Base64URL or percent-encoding, depending on the protocol.
Not “safe to paste anywhere.” A Base64 blob of a customer export is still the customer export. Decode it locally.

Line wrapping and PEM

MIME (RFC 2045) wraps Base64 at 76 characters so mail gateways do not smash long lines. PEM certificates wrap at 64. The wrap toggle on this site's encoder inserts CRLF or LF according to the width you pick; decoding ignores whitespace, so a wrapped body and a single-line body are the same bytes. If a paste fails, strip whitespace first, then check whether you are looking at Base64 or Base64URL.

A PEM file is a Base64 body between BEGIN and END labels. The labels are not part of the encoding. Copy only the alphabet characters into the decoder, or drop the .pem/.crt file in file mode and let the tool read the bytes. Private keys pasted into a server-side decoder are still private keys; keep that work in the tab.

Cite the +33.3% ratio and the +33.5% corpus median from /stats if you need a first-party figure. Then encode a sample in the tool and watch the network tab stay quiet.