Can you remove the = at the end of Base64?

Two encoded strings can look almost alike, except that one uses + and / while the other uses - and _. Some end in =; others do not. These details tell you which representation a system expects. They are a better starting point for a decoding failure than trimming characters until something works.

Base64url changes two alphabet characters

Base64 represents bytes using a limited ASCII alphabet. Base64url substitutes - for + and _ for /. The change makes the spelling easier to use in URLs and filenames; it does not introduce encryption.

The same two bytes, two spellings

FB FF is a byte example, not a text example. These bytes are not a valid UTF-8 string. A text-oriented decoder can therefore reject the result even when the Base64-to-byte conversion itself is correct.

Input bytes in hexadecimal	Base64	Base64url with padding
FB FF	+/8=	-_8=

Padding completes the final group

Base64 represents three bytes with four alphabet characters. One leftover byte needs ==; two need =. A complete three-byte group needs neither. The absence of = therefore does not, by itself, identify a string as Base64url.

Short ASCII text makes the groups visible

Padding does not mean that the original data contained an equals sign. The single character = encodes as PQ==. For non-ASCII text, count bytes rather than displayed characters when reasoning about the final group.

Input text	Bytes in ASCII or UTF-8	Base64
A	1	QQ==
AB	2	QUI=
ABC	3	QUJD
ABCD	4	QUJDRA==

The enclosing protocol decides whether padding can be omitted

RFC 4648 §3.2 requires appropriate padding unless the referring specification explicitly says otherwise. “It goes in a URL” is not enough to decide to remove it. JWS, used by signed JWTs, supplies such a rule: RFC 7515 §2 defines its Base64url representation without trailing = characters.

Accepted by a decoder is not the same as conforming to a protocol

A permissive decoder may accept an unpadded string while an API expects a padded spelling. Producers should follow the API’s format; consumers should validate the alphabet, length and padding rules of that format. The label Base64url alone should not replace that contract.

Length suggests missing padding, not overall validity

To pass known unpadded Base64url to a decoder requiring ordinary padded Base64, translate the two alphabet characters and complete the final four-character group. This is a representation conversion for a known format, not a general repair for unknown input.

Use the length without padding

Length alone is insufficient. Invalid characters and nonzero unused pad bits can still make the representation unacceptable. For signed data, follow the signature specification’s exact input rules rather than decoding and re-encoding the text for appearance before verification.

Length modulo 4	Padding to add	Example
0	None	QUJD
2	==	QQ → QQ==
3	=	QUI → QUI=
1	Not a valid unpadded length	A

Decoding bytes and reading text are separate steps

Base64 decoding yields bytes. Interpreting them as UTF-8 text is another operation. An image or compressed payload will not become readable prose merely because its Base64 is valid. Encoding also does not limit who can read a value; a secret encoded this way remains a secret that needs protection.

What the Online Tools text converter supports

Encoder / Decoder converts input text to UTF-8 bytes for Base64 encoding and interprets decoded bytes as UTF-8 text. It has no direct Base64url mode or binary-file recovery feature. JWT Decoder understands the Base64url segments used in its supported three-part token format.

Round-trip a short text sample

Use Encoder / Decoder to encode A, AB and ABC, then compare the output with the table. For token segments, use JWT Decoder with the made-up sample in JWT decoding versus verification, rather than a live credential.