I decoded Base64 from a message and got an error saying the number of symbols cannot come from a correct encoding. Is the text cut off?
Usually, yes. Base64 is written in groups of 4 symbols, and the last group may have two or three, but never a single one. When one symbol is left over, the tool refuses the text instead of guessing, and that normally means the message was cut off or only partly copied. Ask for the full text again. Missing = signs on their own are fine and are added with a note.
Why a single leftover symbol is impossible
Each Base64 symbol carries 6 bits, and a byte is 8 bits. So the last byte needs at least two symbols, because one cannot hold it. If the number of symbols, after skipping spaces and = signs, leaves a remainder of 1 when divided by 4, there is no original text that could produce that length.
Example: a truncated text
The full encoding of Hello World is:
SGVsbG8gV29ybGQ=
If it reached you cut off after nine symbols, SGVsbG8gV, the tool says: 'The number of symbols (9) cannot come from a correct Base64 encoding. The text looks cut off.' Nine symbols means two complete groups and one lone symbol, which is impossible. Nothing is decoded, not even the sound part at the start.
Compare: only the padding is missing
SGVsbG8, seven symbols with no = at the end, decodes to Hello with the note 'Padding is missing: 1 = sign(s) were added to complete the length.' Here the length is possible, one full group plus three symbols, and only the padding is missing, which carries no data. That is common with URL-safe Base64 and JWTs.
The opposite is refused too: we tried SGVsbG8== with two = signs instead of one, and got a message that there are 2 = signs but the length requires 1.
The riskier case: a cut with no error
Not every cut produces an impossible length. We took the encoding of مرحبا (hello), 2YXYsdit2KjYpw==, and cut it after 11 symbols: 2YXYsdit2Kj. The tool decoded it to مرحب, missing the final letter, with two notes: padding is missing, and the last symbol carries extra bits that were ignored, so the text is not in canonical form and may have been altered. Cut after 10 symbols, no text appeared at all; the tool said the result is not UTF-8 text, because the cut fell in the middle of an Arabic letter.
- A 'padding is missing' note on its own: usually no problem.
- A 'last symbol carries extra bits' note: take care, the text may be cut or altered, so compare the result with what you expect.
- The impossible-length message: the text is definitely incomplete.
What to do
- Paste the text into the Base64 encoder/decoder tool in 'Decode' mode and read the message or notes.
- If the length message appears, go back to the source and copy the whole text. Chat apps may shorten long messages, which need expanding before you copy.
- If the source is a file or an email, ask for it to be sent as an attachment rather than pasted into a message.
- Do not try to complete the text by adding symbols yourself; you would get wrong data.
Remember that messages carrying Base64 are not secret because of the encoding; anyone can decode them. If they hold something you need to keep private, protecting it is the job of the channel they travel through.
Common questions
Do spaces and line breaks count towards the length?
No. The tool skips them and counts only symbols from the alphabet.
Can the tool decode the sound part of a cut-off text?
Not when the length is impossible. It decodes nothing, so it never hands you partial data as if it were complete.
What does 'not in canonical form' mean?
That the last symbol has bits a correct encoding could never write. The tool ignores them and warns you, because it can mean a cut or an edit.