The Base64 I copied from an email is split across many lines. Do I need to remove the line breaks before decoding?

No. Line breaks, spaces and tabs are not in the Base64 alphabet, so the tool skips them, tells you how many it ignored, and decodes the rest. Other characters, such as the > that email apps put in front of quoted lines in a reply, are still refused with their position.

Published · 3 min read

Why Base64 arrives split in the first place

Email systems write attachments as Base64 inside the message, and the email standard wraps that text into short lines. Some other systems do the same to keep it readable. Wrapping does not change the data, because a line break is not a symbol in the alphabet, so whoever decodes the text ignores it.

What the tool did with wrapped text

We took the encoding of مرحبا (hello) and split it over two lines:

2YXYsdit 2KjYpw==

In 'Decode' mode the word came out whole, with the note 'Ignored 1 spaces and line breaks.' When the break was the two-character Windows kind, the tool said it ignored 2. We also tried text with spaces at both ends and a tab in the middle, and the same word came out with 7 ignored.

That count is handy as a check: if you expected a single line and the tool says it skipped dozens of breaks, you may have copied more than you meant to.

What the tool does not skip

When you reply to a message, some email apps put a > in front of every quoted line. We tried the same text with that mark in front of both lines, and the tool refused with 'Position 1: a character that is not in the Base64 alphabet', pointing at the >. It cannot know whether the mark is extra or the text is damaged, so refusing is safer than decoding something that may be wrong.

  • > or | marks at the start of lines in quoted replies: remove them, or copy the text from the original message rather than the reply.
  • Header lines such as Content-Type or Content-Transfer-Encoding before the text: copy only what follows them.
  • An email signature or words after the text: stop at the last symbol; the text often ends with one or two = signs.

Steps

  1. Copy the Base64 block from the message, from its first line to its last, with the lines as they are.
  2. Open the Base64 encoder/decoder tool, choose 'Decode' and paste it.
  3. Read the note about skipped breaks, and any error with its position.
  4. If the result is text, copy it; if it is a file, download it with the button provided.

Do I need a whitespace cleaner?

Not for decoding Base64; the tool skips whitespace itself. The Whitespace cleaner removes stray spaces at line ends and blank lines, but it keeps the line breaks themselves. So if you are going to paste the text into another system that rejects wrapped lines, the simpler route is to decode it here and encode the result again, because this tool's encoded output is always a single line. If the result is a file, download it and then choose it in 'Encode' mode. And remember that an attachment is not protected by being in Base64: it is an encoding anyone can reverse, so if the attachment is sensitive, the protection comes from the channel it was sent through, not from the encoding.

Common questions

Do spaces count towards the length check?

No. The tool checks the length of the symbols alone, after skipping spaces and breaks.

Is the note shown as a warning?

No, it is an information note, because skipping breaks is normal.

My text is one line, yet the tool skipped a space. Why?

You probably copied a space at the start or end. It does not affect the result.