What Is Base64 Encoding — and When Should You Use It?

You have probably seen it without knowing its name: a long string of letters and numbers, sometimes with a + or a / tucked in, often ending in one or two = signs. It shows up in email attachments, website code, login headers, and sign-in tokens. It looks like a secret code. It is not. It is Base64 — a way of writing any data as plain, portable text.

This article explains what Base64 encoding is, how it works in plain language, what the = at the end means, and when you should (and should not) use it. To try it as you read, the free Base64 Encoder converts any text into Base64, with correct handling of non-English characters.

The short answer: a way to write any data as safe text

Base64 is a binary-to-text encoding: it takes any data — text, an image, a file, anything stored as bytes — and rewrites it using only 64 safe characters: A–Z, a–z, 0–9, plus + and /. That is where the name comes from. The = sign is not part of the 64; it is padding, explained below.

The result is ordinary text that can travel through text-only systems, sit inside a web page, or be pasted into a message without getting mangled. The original data is unchanged in meaning — just repackaged — and decoding restores it exactly. The rules are fixed in RFC 4648, so every correct encoder produces the same output for the same input.

Why text-only channels need it

Many systems that move data were built for text. Email was originally designed to carry plain ASCII text, not images or files. JSON, the format most web services use to exchange data, carries text strings, not raw binary. Web addresses, headers, and configuration files are text too. Raw binary does not survive those channels reliably: some byte values are control characters a text system may read as instructions, and others may not be valid characters at all. Send binary through a text-only pipe and it can arrive corrupted, truncated, or rejected.

Base64 solves this by guaranteeing output that every text system tolerates — a trade of larger size for data that survives the journey. You meet it daily: email attachments are carried as Base64, small images are sometimes embedded into a web page as a “data URI”, and web services return binary data inside JSON by Base64-encoding it.

How it works, step by step

Base64 works on the bits of the data, not on its letters. Every byte is 8 bits. Base64 takes 3 bytes at a time (24 bits) and splits them into 4 groups of 6 bits each. Each 6-bit group is a number from 0 to 63, and that number picks one character from the 64-character alphabet. That is the whole trick: 6 bits per character, 64 possible characters, hence the name.

Here is a worked example you can check by hand. Take the word Man. Its three ASCII letters are three bytes: M = 01001101, a = 01100001, n = 01101110. Join them into one 24-bit stream and cut it into four 6-bit groups: 010011 = 19 → T, 010110 = 22 → W, 000101 = 5 → F, 101110 = 46 → u. So Man encodes to TWFu. The bits never changed — they were simply repackaged from three 8-bit boxes into four 6-bit boxes.

One consequence is size: the output is about a third larger than the original. The exact formula is 4 × ceil(n ÷ 3) characters for n bytes — 100 bytes become 136 characters, and 1,000 bytes become 1,336. That growth is the price of text safety.

Also note that Base64 encodes bytes, not letters. For text, the bytes depend on the character encoding — almost always UTF-8 today. This site’s encoder writes your text as UTF-8 bytes first, so characters from languages such as Arabic, Chinese, or French encode correctly and decode back to the exact same text.

What the = at the end means

Not every input divides neatly into groups of 3 bytes. When the last group is short, Base64 pads the output with = characters so the total length stays a multiple of 4. Padding carries no data — it just tells the decoder where the real data ends.

The rule is simple: one leftover byte gives two data characters plus ==; two leftover bytes give three data characters plus =; a full group needs no padding.

Padding also causes confusion when copying strings: some systems strip it, and some decoders require it while others fill it in automatically. If a decoder rejects a string whose length is not a multiple of 4, missing padding is the first thing to check.

Base64 vs base64url: the two characters that break URLs

Standard Base64 has one flaw for web use: + and / have special meanings in URLs. In a query string, + can be read as a space; in a path, / separates segments. Drop a standard Base64 string into a URL unchanged and the server may receive something different from what you sent.

RFC 4648 therefore defines a second alphabet, base64url, for URLs and filenames. It makes exactly two swaps and one behaviour change:

The decoded bytes are identical either way. This is the form used by JSON Web Tokens (JWTs): each of a token’s three dot-separated parts is base64url-encoded, which is why tokens contain – and _ but never +, /, or =.

The practical rule is straightforward. If the encoded value will sit inside a URL, a filename, or a cookie, use the base64url alphabet. If it will sit in a JSON string, an email body, or a data URI, use standard Base64. If a decoder rejects a string full of – and _, it is probably a base64url string being fed to a standard decoder — swap the characters back and restore the padding.

Base64 is not encryption (and not compression, and not a hash)

This is the most important section of this article, because the confusion causes real mistakes.

Base64 is not encryption. Encryption scrambles data with a key, so only someone with the key can read it. Base64 has no key: anyone who receives a Base64 string can decode it in seconds, with no secret and no effort. If you encode a password, an API key, or a private message in Base64 and share the result, you have shared the original in plain sight, wearing a thin disguise. As explained in our guide to what makes a password strong, a password is protected by being long, random, and unique — never by being encoded.

That is also why HTTP Basic Authentication is only safe over HTTPS: the header carries username:password encoded in Base64, which anyone intercepting the request could decode at once. The security comes entirely from the encrypted HTTPS connection around it, not from the encoding inside it.

Base64 is not compression. It makes data larger, not smaller — about a third larger. If a file needs to be smaller, compress it first, and only then encode the result if a text channel demands it.

Base64 is not a hash. A hash produces a fixed-length fingerprint that cannot be reversed; Base64 produces a variable-length output that reverses exactly. One sentence to keep: encoding is for format, encryption is for secrecy, hashing is for integrity. Swapping them is where the trouble starts.

When to use it — and when not to

Use Base64 when a text-only channel must carry binary data (email attachments, JSON or XML payloads with binary fields), when you need to embed a tiny asset in a text document, when a format or API asks for it, or when you want to inspect a value — this site’s encoder handles encoding, and its companion Base64 Decoder handles the reverse.

Do not use Base64 to hide or protect data (use real encryption for secrecy, and proper password hashing for stored passwords); for large files (the 33% overhead adds up — a 10 MB file becomes about 13.3 MB of text); for serving website images (a linked file can be cached and keeps pages smaller); or as a shortcut to URL safety (deleting +, /, or = corrupts the data — convert to base64url instead).

Try it: encode a short piece of text

The fastest way to make Base64 concrete is to encode something yourself. Open the free Base64 Encoder, type or paste a short piece of text, and click Run. Try Hello, World! first — you should get SGVsbG8sIFdvcmxkIQ== — then try a single letter and watch how the padding changes with the length.

If you work with text tools often, the Text Converter Tools category gathers the site’s converters, and all tools lists everything the site offers for free, with no sign-up.

FAQ

Is Base64 the same as encryption?

No. Base64 is an encoding — a reversible change of format with no key. Encryption requires a key, so only the key holder can reverse it. Anyone can decode Base64.

Why does my encoded text end with = or ==?

That is padding. If the last group held only 1 byte, the output gets ==; if it held 2 bytes, it gets =. Padding carries no data; it just keeps the output length a multiple of 4.

Can I use Base64 to hide a password?

No — never. A Base64-encoded password can be decoded by anyone who sees it, with no key and no effort. Passwords should be long, random, and unique, and stored by systems designed for passwords.

What is the difference between Base64 and base64url?

Base64url is the URL- and filename-safe variant from RFC 4648: it replaces + with – and / with _, and usually omits padding. The decoded data is identical.

The bottom line

Base64 exists for one reason: some channels only carry text, and some data is not text. It bridges that gap by repackaging any bytes into 64 safe characters, at the cost of about a third more size and a little padding. Use it whenever a format demands text, use base64url inside URLs, and never mistake it for protection. It is an envelope, not a lock.