URL-Safe Base64 to Image
Strings that travelled through a URL or a JWT often use - and _ where standard Base64 uses + and /. This page decodes that alphabet by default.
Any format accepted: prefixed, raw, wrapped, URL-encoded, URL-safe, or broken.
Your image appears here
Paste on the left — no button to press. Everything stays in your browser.
When you need this
- You pulled a payload out of a JWT segment or a query parameter and it contains
-or_. - A webhook or an OAuth flow handed you an image as a URL-safe string.
- Base64 in a filename or a path segment, where
/would have broken the route.
Why other Base64 converters fail here
The two alphabets differ in exactly two characters, so a URL-safe string fed to a standard decoder produces either an error or — worse — silently wrong bytes.
Tools that only special-case - and ignore _ decode about half the payload correctly, which is the hardest kind of bug to notice.
The error message you get is usually just Invalid character, which does not hint that a different alphabet exists at all.
Frequently asked questions
How do I tell URL-safe Base64 from standard Base64?
Standard Base64 uses + and /. URL-safe replaces them with - and _ so the string can sit inside a URL, a filename or a cookie without escaping. If your string has no +, /, - or _ at all, the two encodings are identical and the distinction does not matter.
What if a string contains both + and - ?
Then it is malformed or has been concatenated from two sources. The decoder will flag whichever character does not belong to the alphabet it selected, and point at the exact position. Guessing here would be worse than failing, because a wrong guess yields a corrupt image rather than an error.
Does the URL-safe mode also handle missing padding?
Yes — the two are independent. URL-safe encoders very often drop the trailing = as well, since it needs escaping in URLs. Both fixes are applied and both are listed in the panel showing what was changed, so the transformation is never hidden from you.
I turned URL-safe mode on and the image is still broken.
Turn it off and compare. If a string happens to contain - or _ as part of a larger non-Base64 text, forcing URL-safe decoding can misread it. The panel reports how many such characters it found, which is usually enough to tell the two cases apart.