Encode Data Safely for URLs and Tokens
Standard Base64 output contains the characters +, /, and =, which are not safe in URLs, query strings, or cookie values. The Base64 URL-safe tool swaps those characters for the URL-friendly - and _ and strips padding, producing strings that can be dropped into a URL without percent-encoding. API developers, auth engineers, and anyone building signed links need this exact variant.
JWT libraries, signed cookie systems, and short-link services all rely on URL-safe Base64. This tool encodes and decodes that format instantly, works with UTF-8 text, and does everything in the browser with no data sent to a server.
Getting the variant right matters because the two alphabets are not interchangeable. A token encoded with the standard alphabet and pasted into a URL can be mangled by the time it reaches the server, producing a signature mismatch or a failed decode. The URL-safe form exists precisely to avoid that class of bugs. You can switch between padded and unpadded output to match whatever the receiving library expects, and the live preview lets you confirm the result before you commit it to a config file, a database row, or a redirect link.
How to Create a URL-Safe Base64 String
- Type or paste the text, token, or binary payload you want to encode into the input box.
- Choose the URL-safe alphabet so
+becomes-and/becomes_. - Decide whether to keep or strip the
=padding characters. - Click Encode and copy the resulting string from the output field.
- Paste it into your URL, query parameter, cookie, or JWT segment and verify the recipient decodes it correctly.
Real Example: A Query Parameter That Survives Transit
An email service encodes a campaign ID with standard Base64 and appends it to a tracking URL. The + in the output is read as a space by the mail client and the link breaks. Re-encoding with the URL-safe alphabet fixes the link because - and _ need no escaping.
| Input | Output |
|---|---|
hello world | aGVsbG8gd29ybGQ |
user:42+admin | dXNlcjo0MithZG1pbg |
Tips for Reliable Round-Trips
- Match the padding — if the receiver expects padding, keep
=; if it uses unpadded tokens like JWTs, strip it. - UTF-8 first — encode non-ASCII text as UTF-8 before applying Base64 so accents and emoji survive.
- Test both directions — decode your own output once to confirm the alphabet and padding settings line up.
- Never hide secrets — Base64 is encoding, not encryption; anyone can read it back.
When URL-Safe Encoding Is the Right Choice
- JWT segments — header and payload use the base64url variant by specification.
- Query parameters — embed tokens in
?token=without worrying about+or/. - Cookie values — avoid characters that break cookie parsing rules.
- Short links — keep generated slugs compact and free of reserved characters.
Frequently Asked Questions
What is the difference between Base64 and URL-safe Base64?
URL-safe Base64 replaces + with - and / with _, and usually removes the = padding, so the output is valid inside URLs without percent-encoding.
Why does my output have no equals signs?
Padding was stripped to keep the string compact. If the decoder complains, re-encode with padding enabled or add the missing = characters manually.
Can I decode standard Base64 with this tool?
Only if the input uses the URL-safe alphabet. For standard +// strings, use the regular Base64 Encode/Decode tool first.
Is URL-safe Base64 the same as Base64URL used in JWTs?
Yes. JWT implementations use the same alphabet with - and _, typically without padding, so this tool produces compatible segments.
Does the tool support Unicode and emoji?
Yes. Text is encoded as UTF-8 before Base64 conversion, so accented characters, CJK text, and emoji all round-trip correctly.
Is URL-safe Base64 secure for passwords?
No. It is reversible encoding, not encryption. Use a dedicated hash or encryption tool for anything secret.
Where is my data processed?
Entirely in your browser. Nothing is uploaded, so you can safely encode API keys and internal identifiers.
Why is the encoded output longer than my input?
Base64 packs 3 input bytes into 4 output characters, so output is about 33 percent larger than the original binary or UTF-8 text.