Decoding a JWT segment
Header and payload are Base64URL. Decoding a single segment inspects claims without a full JWT parser, which is useful when the token is malformed.
Developer🌐 YAS server-sideAPI availablebeginner
Base64 URL Encode
Encodes/decodes URL-safe Base64 — the variant used in JWTs and web APIs.
Processed by YAS · not stored
Ready to runInstant execution
Loading tool…
What does this tool do?
Encodes/decodes URL-safe Base64 — the variant used in JWTs and web APIs.
Why would I use it?
- You are decoding a JWT payload section (header.payload.signature).
- You need Base64 without +, / or = padding in a URL.
- You are working with cookie or token formats.
Real-life example
Input
hello?
Output
aGVsbG8_
The / and + characters become _ and -; padding is omitted.
Input → Process → Output → Next
- Input
- Paste text or URL-safe Base64.
- Process
- YAS converts using the URL-safe alphabet.
- Output
- The converted string.
- Next action
- Use it in URLs, JWTs, or OAuth parameters.
Common mistakes
- Using standard Base64 in a URL (breaks on + and /).
- Decoding URL-safe input with a standard decoder (padding mismatch).
- Treating it as encryption.
What the result means
Same bytes, different alphabet — compatible where standard Base64 is not URL-safe.
Privacy & security
Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.
API
Endpoint
POST https://yas.sh/api/v1/tools/base64-url
Request Header
Content-Type: application/json
cURL
curl -X POST "https://yas.sh/api/v1/tools/base64-url" \
-H "Content-Type: application/json" \
-d '{"input":"hello world","mode":"encode"}'JavaScript
const res = await fetch("https://yas.sh/api/v1/tools/base64-url", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"input": "hello world",
"mode": "encode"
}),
});
const data = await res.json();Python
import requests
r = requests.post("https://yas.sh/api/v1/tools/base64-url", json={"input":"hello world","mode":"encode"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| input | string | Yes | Text |
| mode | string | No (default encode) | encode | decode |
Success response
{ "result": "aGVsbG8gd29ybGQ", "mode": "encode" }Encode/decode using URL-safe Base64 (base64url).
Error responses
400 VALIDATION_ERROR— invalid input or unsupported option.413 PAYLOAD_TOO_LARGE— input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED— rate limit exceeded (60 req/min).
Limits
- Maximum input: 64 KB per request.
- Rate limit: 60 requests/min per IP address.
- Authenticated accounts benefit from higher tier quotas.
Base64 URL Encode: technical reference, use cases and FAQ
How Base64 URL Encode works
Base64URL is the URL- and filename-safe alphabet defined in RFC 4648 §5. It differs from standard Base64 in exactly three ways: + becomes -, / becomes _, and the trailing = padding is usually omitted. Those substitutions matter because + is decoded as a space in query strings, / is a path separator, and = is a key/value delimiter — a standard Base64 string dropped into a URL is corrupted by the URL parser itself.
This variant is what JWTs, OAuth 2.0 PKCE challenges, WebAuthn credential IDs and webhook signatures use. Because padding is omitted, decoders must reconstruct it: the string length modulo 4 determines how many = characters to append, and a length of exactly 1 modulo 4 is invalid and indicates truncation.
When to use it: real-world scenarios
Building an OAuth PKCE challenge
The code_challenge is the Base64URL encoding of the SHA-256 of the verifier, unpadded. Getting the variant wrong produces an authorization error that names nothing useful.
Passing binary data in a URL path
Identifiers, signatures and compact tokens travel safely in path segments and filenames without further percent-encoding.
Verifying a webhook signature
Providers commonly encode HMAC output as Base64URL. Decoding confirms whether a mismatch is a variant problem or a genuinely wrong secret.
Pro tips
- Never store a standard Base64 string in a URL. Convert to the URL variant; percent-encoding the + and / is legal but produces longer, harder-to-debug values.
- If a decoder rejects an unpadded string, append = until the length is a multiple of four. Length ≡ 1 (mod 4) means the value is truncated.
- Base64URL is not encryption. JWT payloads are readable by anyone holding the token.
- When comparing two encoded values, normalise the variant and padding first — the same bytes have several valid textual forms.
Limitations and edge cases
What this tool deliberately does not do, and where it will disagree with other implementations.
- Output is about 33% larger than the input, the same overhead as standard Base64.
- Decoders vary in strictness about padding and about characters outside the alphabet.
- The tool handles text; binary files need the Base64 File tool, which reads bytes directly.
- The API path accepts up to 64 KB per request.
Frequently asked questions
- What is the difference between Base64 and Base64URL?
- Base64URL replaces + with - and / with _ and usually omits padding, so the value is safe in URLs, filenames and path segments. The underlying encoding is otherwise identical.
- Why has my encoded value no equals signs?
- Padding is customarily omitted in the URL variant. Decoders reconstruct it from the string length, which is why a length of 1 modulo 4 is invalid.
- Can I decode a JWT with this?
- Yes, segment by segment — split the token on dots and decode the first two. The JWT Decoder does it in one step and interprets the claims.
- Is Base64URL more secure than Base64?
- No. Neither provides any security; both are reversible encodings. The URL variant only avoids characters that break URLs.
Related tools