Guide

Base64 vs Base64URL: Differences and Valid Examples

Base64URL is a URL-safe variant of Base64: it replaces + with -, replaces / with _, and commonly omits = padding. The decoded bytes can be identical, but a strict standard Base64 decoder may reject the URL-safe text.

Encode or decode

Use the tool immediately, then come back to the guide for troubleshooting notes.

Your input is sent to the server for this request and is not saved as a tool content record. Infrastructure logs may still record request metadata, so do not submit secrets.

Base64 vs Base64URL: Differences and Valid Examples

Base64URL is a URL-safe variant of Base64: it replaces + with -, replaces / with _, and commonly omits = padding. The decoded bytes can be identical, but a strict standard Base64 decoder may reject the URL-safe text.

Supported: .txt

The alphabet and padding are the practical difference

Both encodings split input bytes into six-bit groups and map those groups to printable characters. Standard Base64 uses A-Z, a-z, 0-9, +, and /. Base64URL uses the same letters and digits but substitutes - for + and _ for /.

Standard Base64 commonly includes = padding so the output length is a multiple of four. Base64URL padding depends on the surrounding specification; JWT segments, for example, normally omit it. Do not remove padding unless the receiving format permits that choice.

DetailStandard Base64Base64URL
Characters 62 and 63+ and /- and _
PaddingUsually keeps =Often omitted when the protocol defines how to restore it
Typical contextMIME fields, data fields, standard Base64 APIsURL path/query tokens, filename-safe values, JWT segments
ScriptZip Base64 toolSupported for UTF-8 textNot normalized by the strict standard decoder

Reproduce the same UTF-8 bytes in both forms

The text below contains two U+00FF characters. In UTF-8 each character is encoded as the bytes C3 BF. Standard and URL-safe Base64 represent those same bytes differently because one output character falls at alphabet position 63.

UTF-8 input
ÿÿ

Paste this text into the combined Base64 tool in Encode mode.

Standard Base64 output
w7/Dvw==

This is the exact output produced by ScriptZip's standard Base64 encoder.

Base64URL form without padding
w7_Dvw

The slash becomes an underscore and the padding is omitted. This is explanatory; the ScriptZip Base64 tool does not offer a Base64URL mode.

Base64 is encoding, not encryption. Anyone who has the value can decode it without a secret key.

Why a strict decoder rejects the other alphabet

A strict Base64 decoder validates every character and the padding structure. An underscore is not part of the standard alphabet, so pasting w7_Dvw into ScriptZip's standard decoder returns an invalid Base64 error instead of guessing which variant you intended.

To convert a Base64URL value for a standard decoder, only do so when the governing specification confirms that it is Base64URL. Replace - with + and _ with /, then restore enough = characters to make the length a multiple of four. Blindly applying that process to arbitrary text can hide a format error.

  1. Identify the protocol or field that produced the value.
  2. Confirm whether it specifies standard Base64 or Base64URL and whether padding is optional.
  3. Use ScriptZip's combined Base64 tool only for standard Base64 that decodes to UTF-8 text.
  4. For a JWT, use JWT Decoder so the three Base64URL segments are handled in their actual token context.

Choose the format from the specification, not convenience

API and configuration fields

Follow the API documentation exactly. A field named base64 may require the standard alphabet and padding, while a token field may define Base64URL.

URLs and filenames

Base64URL avoids +, /, and often =, which reduces escaping problems. It is still not automatically safe to trust as a path or identifier.

JWT segments

JWT uses Base64URL for the header and payload segments. Decoding reveals JSON but does not verify the signature or prove the token is trusted.

Binary data

Base64 can represent arbitrary bytes, but ScriptZip's public Base64 page is a UTF-8 text workspace and does not accept binary file uploads.

Size, security, and decoding limits

Base64 expands data because four encoded characters represent three input bytes before padding. It is useful when a text-only channel must carry bytes, but it is not compression and should not be selected to reduce a payload.

Neither Base64 variant hides information. Do not use either one for passwords, API keys, session secrets, or private customer data. Use encryption and access controls designed for the threat model, and avoid placing secrets in browser-delivered values in the first place.

Related tools