Encoding
Decode Base64URL to text
Base64URL decoding turns URL-safe strings (the - and _ alphabet, no padding) back into text. It is the step behind reading a JWT: the header, payload and signature are three Base64URL strings joined by dots. The decoder restores the padding for you, accepts the standard alphabet too, and reads the bytes as UTF-8, so non-ASCII claims come back intact.
How to use Base64URL Decode
- Open Base64URL Decode in the Toolbox101 app.
- Paste one Base64URL string, often the middle JWT segment, into the
Base64URLbox. - Read the decoded text in the
Outputbox; the alphabet swap and padding are handled for you. - Click
Copyto use the decoded value in your code or terminal.
Worked example
Base64URL Decode returns the output below for this input.
Input
aGVsbG8_PwOutput
hello??Check it yourself: open Base64URL Decode and enter the same input.
Frequently asked questions
Why can plain Base64 decoders not read JWT segments?
Because JWT segments use Base64URL: - and _ stand in for + and /, and the padding is stripped. The browser's atob throws on those characters, so a generic decoder built on it refuses token segments unless the alphabet is swapped first. This one swaps it for you.
Do I have to add = padding before decoding?
No. The decoder restores padding internally, so unpadded strings decode exactly like padded ones. The only length that fails is one that leaves a single character over, which cannot hold a whole byte and means the input is truncated or corrupted.
Can I decode a whole JWT here?
One segment at a time, since the dots are not part of the alphabet. For the whole token, the JWT Decoder splits the three parts, decodes the header and payload and shows the claims.
How do I check the decoded result?
Paste the decoded text into the Base64URL Encode tool and you should get the original string back, minus any = padding. If it comes back different, the input carried stray characters or was cut off before decoding.
Use Base64URL Decode now
Runs in your browser. Nothing you type is uploaded.