The process, conceptually
Encoding takes raw bytes — from a text string or a file — and groups them 3 at a time into 24-bit chunks, then splits each chunk into four 6-bit values mapped to the Base64 alphabet (A–Z, a–z, 0–9, +, /). If the input isn't an exact multiple of 3 bytes, = padding fills out the final group.
"Hi" (2 bytes) → padded output: "SGk="
Encoding text vs. encoding a file
Encoding text first requires deciding on a character encoding (almost always UTF-8 today) to turn the string into bytes before Base64 ever gets applied — this matters for anything beyond plain ASCII, since the same visible text can produce different byte sequences (and thus different Base64 output) depending on the source encoding. Encoding a file skips that step entirely — you're encoding the raw bytes already on disk, regardless of whether they represent text, an image, or a binary blob.
Line wrapping: a historical quirk that still shows up
Older standards (like MIME email attachments, per RFC 2045) require Base64 output to be wrapped at 76 characters per line. Most modern tools and APIs (JSON, JWTs, data URIs) expect a single unbroken line instead — pasting line-wrapped Base64 into a context expecting one continuous string will fail to decode correctly, since the embedded newlines aren't valid Base64 alphabet characters. Always check whether your destination expects wrapped or unwrapped output before encoding.
Standard vs. URL-safe alphabet
If the encoded output is going into a URL, filename, or anywhere + and / would cause a conflict (see the Complete Guide to Base64), use the URL-safe alphabet (- and _ in place of + and /) instead of standard Base64 — encoding with the wrong variant for the destination is one of the most common Base64 integration bugs.
Common mistakes
- Encoding a string without deciding on a character encoding first. "The same text" can produce different Base64 output depending on whether the underlying bytes were UTF-8, UTF-16, or another encoding.
- Forgetting line-wrapping requirements for older systems, like legacy email/MIME contexts that still expect 76-character line breaks.
- Using standard Base64 where URL-safe is expected, producing output with
+//characters that break the destination context.
FAQ
Does encoding a string always produce the same Base64 output?
Only if the underlying byte encoding (usually UTF-8) is consistent — the same visible text encoded via a different character set first can produce different Base64 output.
Why does my encoded output have line breaks I didn't expect?
Some tools follow the older MIME convention of wrapping at 76 characters — strip the newlines, or use a tool configured for unwrapped output, if your destination expects one continuous string.
Should I use standard or URL-safe Base64?
URL-safe (-/_ instead of +//) if the result goes into a URL, filename, or JWT; standard Base64 otherwise.
Encode text or files instantly with the Base64 Encoder/Decoder — everything happens in your browser, nothing is uploaded.