Base64 URL-safe

URLセーフなBase64(Base64url)のエンコード・デコード

プレーンテキスト

Base64

ローカルで実行 · シークレットの貼り付けも安全
Base64出力...

Base64urlエンコードとは?

Base64urlは、URL・ファイル名・その他のコンテキストで標準Base64の文字+と/が問題を引き起こす場面に特化して設計されたBase64エンコードの変種です。RFC 4648 Section 5で定義されており、Base64urlは+を-(ハイフン)に、/を_(アンダースコア)に置き換え、末尾の=パディング文字を省略します。その結果として得られる文字列は、追加のパーセントエンコードを必要とせず、URLクエリパラメータ・ファイル名・HTTPヘッダーに直接埋め込むことができます。

標準Base64(RFC 4648 Section 4)はA–Z・a–z・0–9・+・/の64文字を使用します。+と/はURLで予約されています。+はクエリ文字列(application/x-www-form-urlencoded)でスペースとして解釈され、/はパス区切り文字です。そのため標準Base64をURL内で使用するにはこれらの文字をパーセントエンコード(%2B・%2F)する必要があり、文字列が長くなり読みにくくなります。Base64urlは最初からURLセーフな文字を使用することでこの問題を完全に解消します。

Base64urlの最も代表的な用途はJSON Web Token(JWT)です。JWTの3つのセグメント——ヘッダー・ペイロード・署名——はすべてBase64urlでエンコードされています。OAuth 2.0のPKCEコード検証値・WebAuthnチャレンジ値・多くのAPIトークン方式もBase64urlに依存しています。このエンコードを理解することは、認証・認可・暗号データ交換を扱う開発者にとって不可欠です。

このBase64urlツールを使う理由

Base64urlとテキストまたはバイナリデータの相互変換をブラウザ上で直接行えます。エンコードとデコードの両方に対応し、パディングと文字置換を自動処理します。JWTトークンのデバッグ、PKCEコードチャレンジの生成、URLセーフな識別子の作成など、あらゆる場面でブラウザ内でローカルに処理が完結するため、遅延ゼロかつサーバーへの通信も不要です。

即時変換
入力と同時に出力が更新されます。テキストをBase64urlにエンコード、またはBase64urlをテキストにデコードを遅延ゼロで実行——フォーム送信もページリロードも不要です。
🔗
URLセーフな出力
出力はURL・ファイル名・HTTPヘッダーで安全な文字のみを使用します:A–Z・a–z・0–9・ハイフン・アンダースコア。パーセントエンコードは不要です。
🔒
プライバシー優先の処理
エンコードとデコードはすべてブラウザ内でローカルに実行されます。ここに貼り付けたJWTトークン・OAuthシークレット・APIキーがサーバーに送信されることはありません。
🏛️
標準準拠
RFC 4648 Section 5を正確に実装しています:-と_が+と/を置き換え、パディングは省略されます。JWTライブラリ・OAuth 2.0 PKCE・WebAuthn実装との互換性があります。

Base64urlのユースケース

JWTトークンの検査
JWTの各セグメント(ヘッダー・ペイロード)をデコードして、JWTライブラリをインポートしたり署名を検証したりせずに、クレーム・有効期限・署名アルゴリズムを確認できます。
OAuth 2.0 PKCEフロー
PKCEのcode_verifierとcode_challengeの値を生成・検証できます。code_challenge_method S256は、code_verifierのSHA-256ハッシュをBase64urlエンコードした値を必要とします。
WebAuthn / FIDO2連携
WebAuthnのチャレンジ・クレデンシャルID・アテステーションデータは、ブラウザと依拠当事者サーバー間でBase64url文字列として送受信されます。これらをデコードして登録・認証フローをデバッグできます。
APIトークンの生成
ランダムなバイトからURLセーフなトークンを生成して、パスワードリセットリンク・メール認証・セッション識別子に活用できます。Base64urlはエスケープなしにURLで機能するコンパクトな文字列を生成します。
DevOpsとCI/CDパイプライン
バイナリの設定値(証明書・鍵)をBase64url文字列として環境変数やYAMLファイルに保存できます。標準Base64と異なり、出力にはシェル展開やYAML構文と衝突する文字が含まれません。
データエンジニアリング
バイナリ識別子・ハッシュ・チェックサムをBase64urlとしてエンコードし、ファイル名・データベースキー・CSVカラムで使用できます。+と/があると解析が壊れたりエスケープが必要になる場面で有効です。

標準Base64 vs Base64url

Base64urlと標準Base64の違いはちょうど3点です。エンコードアルゴリズムは同一——変わるのはアルファベットとパディングの扱いだけです:

特徴標準(RFC 4648 §4)Base64url(RFC 4648 §5)
Index 62+-
Index 63/_
Padding= (required)Omitted

この3つの違いにより、標準Base64とBase64urlの相互変換は簡単です:+を-に、/を_に置き換え、末尾の=を除去します。逆方向は-を+に、_を/に置き換え、長さが4の倍数になるようパディングを追加します。ほとんどの言語がネイティブのBase64urlサポートを提供しているため、手動変換は不要です。どちらの変換も完全に可逆かつロスレスであり、元のバイト列を正確に保持します。

エンコード比較表

以下の表は同じ入力を標準Base64とBase64urlでエンコードした結果を示しています。URLセーフ版ではパディング文字(=)が除去され、+と/が-と_に置き換えられていることを確認できます:

入力標準Base64Base64url(パディングなし)
HelloSGVsbG8=SGVsbG8
AQQ==QQ
1+1=2MSsxPTI=MSsxPTI
subject?ref=1c3ViamVjdD9yZWY9MQ==c3ViamVjdD9yZWY9MQ
👍 (thumbs up)8J+RjQ==8J-RjQ

コード例

主要な言語でBase64url文字列をエンコード・デコードする方法です。各例はURL・ファイル名・HTTPヘッダーで安全に使用できる出力を生成します:

JavaScript (browser)
// Encode to Base64url
function toBase64url(str) {
  return btoa(unescape(encodeURIComponent(str)))
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}
toBase64url('Hello!') // → "SGVsbG8h"

// Decode from Base64url
function fromBase64url(b64url) {
  const b64 = b64url.replace(/-/g, '+').replace(/_/g, '/')
  const pad = (4 - b64.length % 4) % 4
  return decodeURIComponent(escape(atob(b64 + '='.repeat(pad))))
}
fromBase64url('SGVsbG8h') // → "Hello!"
Node.js
// Native base64url support since Node 15.7
const encoded = Buffer.from('Hello!').toString('base64url')
// → "SGVsbG8h"

const decoded = Buffer.from('SGVsbG8h', 'base64url').toString()
// → "Hello!"

// Decode a JWT payload
const jwt = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...'
const payload = JSON.parse(Buffer.from(jwt.split('.')[1], 'base64url').toString())
// → { sub: "1234567890" }
Python
import base64

# Encode to Base64url (no padding)
encoded = base64.urlsafe_b64encode(b'Hello!').rstrip(b'=').decode()
# → "SGVsbG8h"

# Decode from Base64url (re-add padding)
def b64url_decode(s: str) -> bytes:
    s += '=' * (4 - len(s) % 4)  # restore padding
    return base64.urlsafe_b64decode(s)

b64url_decode('SGVsbG8h')  # → b'Hello!'
Go
package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    // Encode to Base64url (no padding)
    encoded := base64.RawURLEncoding.EncodeToString([]byte("Hello!"))
    fmt.Println(encoded) // → "SGVsbG8h"

    // Decode from Base64url
    decoded, _ := base64.RawURLEncoding.DecodeString("SGVsbG8h")
    fmt.Println(string(decoded)) // → "Hello!"
}

よくある質問

Base64とBase64urlの違いは何ですか?
Base64urlは標準Base64アルファベットの+を-に、/を_に置き換え、末尾の=パディング文字を省略します。これにより、追加エンコードなしにURL・クエリパラメータ・ファイル名・HTTPヘッダーで安全に使用できる出力が得られます。基礎となるアルゴリズム(バイトを6ビットグループに分割してASCII文字にマッピングする処理)は同一です。
JWTトークンが標準Base64ではなくBase64urlを使う理由は?
JWTはURLクエリパラメータやHTTP Authorizationヘッダーで頻繁に送受信されます。標準Base64の+と/はURLでパーセントエンコードが必要となり、文字列が長くなり単純な文字列比較が壊れます。JWT仕様(RFC 7519)は、トークンがデフォルトでコンパクトかつURLセーフになるよう、パディングなしのBase64urlを義務付けています。
標準Base64をBase64urlに変換するには?
すべての+を-に、/を_に置き換え、末尾の=をすべて除去します。JavaScriptの場合:base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')。Pythonの場合:base64.urlsafe_b64encode(data).rstrip(b'=')。ほとんどのモダンな言語は専用のBase64urlエンコード関数も提供しています。この変換は、標準のBase64を出力する古いライブラリと、Base64urlを期待するJWTバリデーターやOAuth 2.0サーバーなどの現代的なシステムを統合する際によく必要になります。
Base64urlエンコードは可逆ですか?
はい。Base64urlは完全に可逆です。デコードするには、-を+に、_を/に置き換え、長さが4の倍数になるよう=パディングを追加してから、標準Base64としてデコードします。デコードされた出力は元の入力とバイト単位で同一です。
Base64urlはデータの暗号化に使えますか?
いいえ。Base64urlはエンコードであり、暗号化ではありません。秘密性なしにバイナリデータをテキストセーフな形式に変換します——誰でもデコードできます。データを保護する必要がある場合は、まず適切なアルゴリズム(AES・ChaCha20)で暗号化し、その後に暗号文をBase64urlエンコードして転送してください。
Base64urlでパディングが省略される理由は?
パディング文字(=)はデコーダーが文字列の長さから不足バイト数を計算できるため不要です:(4 - length % 4) % 4で必要なパディングが求まります。パディングを省略することで文字列が短くなり、URLでパーセントエンコードが必要な=文字も回避できます。RFC 4648 Section 5はBase64urlでのパディング省略を明示的に認めています。
パディング付きのBase64url文字列をコードで扱うには?
パディング=を保持するBase64url文字列を生成するシステムも存在します。ほとんどのデコーダーはこれを正しく処理します。対応していない場合はデコード前に末尾の=を除去してください。逆に、ライブラリがパディングを必要とする場合はこれを計算して追加します:const padded = str + '='.repeat((4 - str.length % 4) % 4)。パディング数は文字列の長さから決定論的に求まるためこれは有効です。