BYTETOOLS

Base64URL Encoder

Encode text to URL-safe Base64URL online — the JWT variant with - and _ instead of + and /, no padding. UTF-8 aware, instant and 100% in your browser.

What is the Base64URL Encoder?

The ByteTools Base64URL Encoder converts text into the URL-safe Base64 variant defined in RFC 4648 §5: the + and / of standard Base64 become - and _, and the trailing = padding is dropped.

  • RFC 4648 §5 base64url alphabet: - and _ instead of + and /
  • Padding stripped by default, with a toggle to keep it
  • UTF-8 aware — full Unicode support
  • Input byte and output character counts
  • Live encoding, one-click copy
  • 100% client-side — safe for secrets

How to use the Base64URL Encoder

  1. 1

    Type or paste the text to encode.

  2. 2

    Leave padding off for JWT-style output, or toggle it on if your consumer requires =.

  3. 3

    Read the Base64URL result as it updates live.

  4. 4

    Copy it with one click.

About the Base64URL Encoder

The ByteTools Base64URL Encoder converts text into the URL-safe Base64 variant defined in RFC 4648 §5: the + and / of standard Base64 become - and _, and the trailing = padding is dropped. The result can be placed directly in URLs, filenames, cookies and JWT segments without any percent-escaping.

Your text is first encoded to UTF-8 bytes, so any Unicode input — accents, CJK, emoji — round-trips correctly. A toggle lets you keep the = padding for the rare consumers that require it, and the tool reports both the input byte count and the output length.

Encoding happens 100% locally in your browser, live as you type. Nothing is uploaded, logged or stored, so it is safe for tokens, secrets and other sensitive values.

Frequently asked questions

What is Base64URL and how is it different from Base64?

Base64URL is the URL- and filename-safe variant of Base64 defined in RFC 4648. It encodes identical data but swaps + for - and / for _, and usually omits the trailing = padding. Standard Base64 breaks inside URLs because + means a space and / separates paths; Base64URL avoids both.

Why do JWTs use Base64URL instead of Base64?

JWTs travel in HTTP headers, query strings and cookies, where +, / and = would need escaping and can be corrupted by intermediate systems. Each of a JWT's three segments is Base64URL-encoded without padding, which is exactly the default output of this tool.

Should I include the = padding or not?

Omit it unless the system consuming the value explicitly requires it. JWT and most web APIs expect unpadded Base64URL. Padding only exists so decoders can determine length in streaming scenarios, and modern decoders can reconstruct it from the string length.

Is Base64URL encoding a form of encryption?

No. It is a reversible transport encoding — anyone can decode it instantly, which is also why you can read JWT payloads without the signing key. Use real encryption if the content must stay confidential.

Is my text uploaded when I encode it?

No. Encoding is pure client-side JavaScript in your browser tab. Your input is never transmitted or stored, making the tool safe for API keys and tokens.

Related tools