I am putting a Base64 value inside a link. Should I choose the URL-safe alphabet, drop the = signs, or both?

For a link or a file name, choose 'URL-safe alphabet', because standard Base64 can contain + and /, each of which means something in a URL, and the URL-safe form writes - and _ instead. Dropping the = signs is optional and saves a character or two, provided the receiving system accepts unpadded values. This tool decodes both forms.

Published · 3 min read

Where the problem actually shows up

Many values contain neither + nor /, so the two forms look identical. We encoded the Arabic word عرض (offer) both ways and got the same output, 2LnYsdi2. That is why a link can work in testing and fail with another value. The problem only appears when the bytes form certain combinations. A short example where / shows up:

YT4/

That is the short text a>? encoded with the standard alphabet. With the URL-safe alphabet it became YT4_. Another example: order?id=5 gave b3JkZXI/aWQ9NQ== in standard form, and b3JkZXI_aWQ9NQ in URL-safe form with 'No padding'.

Why + and / cause harm in a link

  • / separates parts of the path, so a value containing / in the path looks like two folders.
  • + can be read as a space in query values, so the value reaches the server with a space instead of + and fails to decode.
  • = separates a name from its value in the query. Most systems tolerate it at the end of a value, but not all do.

The URL-safe alphabet solves the first two completely. 'No padding' solves the third.

Which option to switch on

  • The value goes in a link path or a file name: tick 'URL-safe alphabet'. This is the important one.
  • The value goes in a query after ?: tick URL-safe, and tick 'No padding' if the receiving system accepts it, as JWTs do.
  • The receiving system requires standard Base64: tick nothing, then encode the output with the URL encoder/decoder in 'Component' mode, so + becomes %2B, / becomes %2F and = becomes %3D.

Steps

  1. Open the Base64 encoder/decoder tool and choose 'Encode'.
  2. Type the value or choose a file.
  3. Tick 'URL-safe alphabet', then 'No padding' if you need it.
  4. Copy the output and put it in the link.

And when decoding?

You need not choose anything. The tool detects the alphabet itself and names it in the summary: decoding YT4_ gave back 'a>?', and the tool reported the URL-safe alphabet. Missing padding is filled in with a note. Mixing both alphabets in one value is refused, though: we tried Pz8/Pz8_ and got a message that the text mixes the standard and URL-safe alphabets. That usually happens when part of a value was edited by hand.

Remember that URL-safe means 'safe to write inside a link', not 'safe from being read'. Anyone who sees the link can decode the value, so put nothing in it you would not want read.

Common questions

Does the data change when I choose URL-safe?

No. The bytes are the same; only two symbols of the alphabet change: - for + and _ for /.

Why do the two options not work with 'Output a data URI'?

Because a data URI always uses the standard alphabet with padding, so the tool ignores the two options and says so.

How many characters does dropping padding save?

One or two at the end of the value, depending on the data length. In the order?id=5 example it saved two.