The = at the end of Base64 is padding, not a character from the original text. Base64 groups three input bytes into four output characters. A final group with one or two input bytes needs two or one padding characters respectively in the standard padded form.
Why one or two padding characters appear
Each Base64 data character represents six bits. Three bytes supply 24 bits, which fit four characters exactly. With one remaining byte, two data characters are followed by ==. With two remaining bytes, three data characters are followed by =. Padding fills the output group; it does not add bytes to the decoded result.
Use byte length, not visible character count
The examples f, fo and foo occupy one, two and three UTF-8 bytes. Korean text and emoji may use several bytes per visible character. For example, 😀 uses four UTF-8 bytes and becomes 8J+YgA==. Counting letters or emoji on the screen is therefore not enough to predict padding.
Can missing padding be restored?
When the receiving format permits unpadded input, remove whitespace and inspect the length of the data characters. A remainder of 2 when divided by 4 needs ==; a remainder of 3 needs =; a remainder of 0 needs no padding. A remainder of 1 cannot be repaired by adding padding. It indicates malformed or truncated data.
Why Zg works here but Zg= fails
Decodex accepts entirely unpadded Base64 and restores its final padding, so Zg decodes to f. Zg== is already complete. Zg= is partially padded and has an invalid total length, so this tool rejects it rather than silently changing a malformed input. A=AA and Zg=== also fail. Adding or deleting = without checking the format can hide a copying mistake.
When should you keep =?
Keep the encoder’s padding unless the target protocol explicitly permits or requires its omission. Standard Base64 and a particular Base64URL-based protocol may have different requirements. If a downstream API reports incorrect padding, first check its specification and whether any characters were lost during copying. Do not repeatedly add = until an error disappears.
Try this example
| Text | UTF-8 bytes | Base64 | Padding |
|---|---|---|---|
f | 1 | Zg== | == |
fo | 2 | Zm8= | = |
foo | 3 | Zm9v | — |
Common questions
Can an encoded string have no =?
Yes. If the byte count is a multiple of three, padded Base64 needs no =. Some protocols also deliberately omit padding from incomplete final groups.
Is = part of the original password or text?
No. A trailing Base64 padding character describes the final encoded group. If the original text contains =, that byte is encoded like any other input byte.
References
More Base64 guides
Base64 vs Base64URL: differences, padding and decoding examples
Compare Base64 and Base64URL with tested examples. Learn why + and / become - and _, when padding is omitted, and how to decode URL-safe UTF-8 text.
JavaScript Base64 with Unicode: fix btoa() errors using UTF-8
Encode and decode Korean, Hindi and emoji in JavaScript with TextEncoder, btoa, atob and TextDecoder. Includes tested Unicode-safe code and browser examples.