最終更新:
URL の文字数制限とベストプラクティス
ブラウザ・サーバー別の URL 文字数制限
URL の上限はブラウザとサーバーの両方で独立して適用されます。ブラウザ側の制限はリクエスト送信前にクライアントで判定され、サーバー側の制限はリクエスト受信時にヘッダーサイズとして評価されます。両者のうち厳しいほうがボトルネックになるため、サーバー設定だけでなくクライアント環境も考慮する必要があります。
| 環境 | URL 上限 | 備考 |
|---|---|---|
| Google Chrome | 2,097,152 文字 | Blink エンジンの内部バッファサイズに由来 |
| Mozilla Firefox | 65,536 文字 | 超過するとアドレスバーで切り詰め |
| Safari | 80,000 文字以上 | WebKit の内部制限、明確な上限は非公開 |
| Microsoft Edge | 2,097,152 文字 | Chromium ベースで Chrome と同等 |
| Internet Explorer 11 | 2,083 文字 | 歴史的な上限 (うちパス部分は最大 2,048 文字)。現行ブラウザは実装依存 |
| Apache (デフォルト) | 8,190 バイト | LimitRequestLine で変更可能 |
| Nginx (デフォルト) | 8,192 バイト | large_client_header_buffers の既定 (4 × 8k)。リクエストラインが 1 バッファを超えると 414 エラー |
| IIS | 16,384 文字 | レジストリ設定で変更可能 |
| Cloudflare | 16 KB (16,384 バイト) | 公式の接続制限一覧に URL 上限として明記 (2026 年 8 月時点) |
| AWS ALB / CloudFront | 8,192 バイト | リクエストライン全体 (メソッド + URL + HTTP バージョン) |
サーバー側の制限がバイト単位で定義されている点に注意してください。URL に ASCII 以外の文字が含まれる場合、パーセントエンコーディング後のバイト数で評価されるため、見た目の文字数よりも実際の消費量が大きくなります。Apache の 8,190 バイトは、日本語を含む URL では約 900 文字分に相当します。
SEO に最適な URL の長さ
Google は URL の長さを直接的なランキング要因としていませんが、短く意味のある URL はクリック率やユーザー体験に好影響を与えます。検索結果では URL の末尾が省略されて切り詰められることがあり、その幅は文字数ではなく表示ピクセル幅や画面サイズによって変わります。特定の文字数を目標にするより、パスを短く要点だけにまとめておくほうが、表示されたときに内容が伝わりやすくなります。
URL のパスにはキーワードを含め、単語の区切りにはハイフン (-) を使用します。アンダースコア (_) は Google が単語の区切りとして認識しないため避けましょう。ディレクトリ階層は 3 階層以内に抑え、不要なパラメータやセッション ID を URL に含めない設計が推奨されます。
URL エンコーディングと文字数の関係
URL に日本語を含める場合、UTF-8 でエンコードされるため文字数が大幅に増加します。日本語 1 文字は 3 バイトの UTF-8 で表現され、パーセントエンコーディングにより 9 文字 (例: %E6%96%87) に展開されます。10 文字の日本語パスは、エンコード後に 90 文字になる計算です。
この膨張を考慮すると、日本語を URL パスに使用する場合はできるだけ短い表現を選ぶか、英語のスラッグを採用するほうが安全です。クエリパラメータに日本語を含める場合も同様で、検索キーワードなどは URL 全体の長さに注意が必要です。
エンコーディングの膨張率は文字種によって異なります。ASCII 文字 (英数字、ハイフン、ピリオドなど) はエンコード不要で 1 文字 = 1 文字のままですが、スペースは %20 で 3 文字、日本語は 1 文字あたり 9 文字に膨張します。絵文字はさらに深刻で、UTF-8 で 4 バイトを消費するため、1 文字が %F0%9F%98%80 のように 12 文字に展開されます。URL に絵文字を含めるケースは稀ですが、ユーザー入力をクエリパラメータに渡す場合は想定外の膨張に注意が必要です。
二重エンコーディングも実務で頻出する落とし穴です。既にエンコード済みの %E6%96%87 を再度エンコードすると %25E6%2596%2587 となり、9 文字が 15 文字に膨張します。フレームワークやライブラリが自動的にエンコードを行う場合、手動エンコードとの二重適用が発生しやすいため、エンコード処理の責務を明確に分離することが重要です。
クエリパラメータの制限と設計
クエリパラメータ (?key=value&key2=value2) は URL の一部としてカウントされます。パラメータが増えるほど URL は長くなり、サーバー側の上限に達するリスクが高まります。特に検索フィルターやトラッキングパラメータが多い場合は注意が必要です。
GET リクエストで大量のパラメータを送信する設計は避け、複雑な条件は POST リクエストのボディに移行することを検討しましょう。UTM パラメータなどのトラッキング用途では、utm_source、utm_medium、utm_campaign の 3 つで合計 100 文字以内に収めるのが実用的です。
フラグメント識別子 (#section-name) は URL の一部ですが、サーバーには送信されません。ブラウザがローカルで処理するため、サーバー側の URL 長制限には影響しませんが、ブラウザ側の制限にはカウントされます。SPA (Single Page Application) でクライアントサイドルーティングにフラグメントを多用する場合、ブラウザの URL 長制限を意識する必要があります。
実務での推奨ガイドライン
ブラウザやサーバーの制限を総合すると、URL 全体を 2,000 文字以内に収めるのが安全な基準です。これは最も制限の厳しい Internet Explorer 11 の上限 (2,083 文字) を下回り、ほぼすべての環境で問題なく動作します。
API のエンドポイント設計では、リソースの識別子 (UUID など) が 36 文字を占めることを考慮し、ベース URL とパスの合計を 200 文字以内に設計すると余裕があります。リダイレクトチェーンでは各段階で URL が変わるため、最終的な URL が制限内に収まることも確認しましょう。
ただし、IE 11 のサポートが終了した現在、2,000 文字という基準は保守的すぎる場合もあります。モダンブラウザのみをサポートする場合は、サーバー側の制限 (Nginx のデフォルト 8,192 バイト、Apache の 8,190 バイト) が実質的なボトルネックになります。CDN やロードバランサーを経由する構成では、各レイヤーの制限を個別に確認する必要があります。
URL が制限を超えた場合、サーバーは HTTP ステータスコード 414 URI Too Long を返します。このエラーはクライアント側で検知しにくく、ユーザーには「ページが見つかりません」と同様の体験になるため、事前の設計段階で URL 長を管理することが重要です。
意外と知らないトリビア
RFC 2616 では URL の長さに明確な上限を定めていませんが、かつての Internet Explorer が 2,083 文字という制限を持っていたため、この数値が事実上の業界標準として長年使われてきました。IE のサポート終了後も、多くの Web 開発ガイドラインが「2,000 文字以内」を推奨しているのはこの名残です。
なお、RFC 2616 は 2014 年に RFC 7230〜7235 に分割・改訂され、2022 年には RFC 9110〜9112 へ再編されました。現行の RFC 9112 (Section 3) では「すべての HTTP 送受信者は少なくとも 8,000 オクテットのリクエストライン長をサポートすることが推奨される (RECOMMENDED)」と記載されており、これが現代の HTTP 仕様における実質的な推奨最小値です。
data: URI は通常の URL とは異なり、URL 自体にデータを埋め込むスキームです。Base64 エンコードされた画像を data:image/png;base64,... の形式で埋め込む場合、URL が数万文字に達することがあります。Chrome はこれを処理できますが、一部のメールクライアントやメッセージングアプリでは切り詰められるため、外部リソースへの参照に置き換えるほうが安全です。
よくある失敗パターン
- URL パスに日本語をそのまま使用し、パーセントエンコーディングによる膨張を考慮していない。日本語 1 文字は URL エンコード後に 9 文字に展開されるため、10 文字の日本語パスが 90 文字になり、想定外の長さになります。
- UTM パラメータやトラッキングパラメータを際限なく追加し、URL が数百文字に膨れ上がる。メール本文や SNS でシェアされた際に URL が途切れ、リンク切れの原因になります。
- URL の末尾にスラッシュがある場合とない場合 (
/blog/と/blog) を別の URL として扱ってしまい、重複コンテンツが発生する。canonical URL を統一し、301 リダイレクトで正規化しましょう。 - URL に大文字と小文字を混在させる。多くの Web サーバー (Linux ベース) は URL を大文字・小文字で区別するため、
/Blog/Articleと/blog/articleは別のリソースとして扱われます。URL は一貫して小文字を使用するのが安全です。
プロのテクニック
- URL のパスには英語のスラッグを使用し、単語の区切りにはハイフン (
-) を使う。アンダースコア (_) は Google が単語の区切りとして認識しないため、SEO の観点からハイフンが推奨されます。 - GET リクエストで大量のパラメータを送信する設計は避け、複雑な検索条件は POST リクエストのボディに移行する。URL の長さ制限に依存しない堅牢な設計になります。
- URL 短縮サービス (bit.ly、t.co など) は SNS やメールでの共有時に有効ですが、リダイレクトが 1 段追加されるためレイテンシが増加します。また、短縮サービスが停止すると全リンクが無効になるリスクがあります。自社ドメインで短縮 URL を運用する (
example.com/go/xxx) ほうが、長期的な信頼性と分析の自由度を確保できます。 - URL の設計段階で 文字数とバイト数の違いを意識しておくと、エンコーディングによる膨張を事前に見積もれます。特にマルチバイト文字を含む URL では、文字数ベースの制限とバイト数ベースの制限を混同しないことが重要です。
まとめ
URL の文字数制限はブラウザやサーバーによって異なりますが、2,000 文字以内を目安にすれば実用上の問題はありません。モダンブラウザのみをサポートする場合でも、サーバーや CDN の制限 (おおむね 8 KB〜16 KB) が実質的なボトルネックになるため、URL 設計時にはバイト数ベースの制限も考慮しましょう。SEO の観点ではパスを短く要点だけにまとめ、日本語の URL エンコーディングによる膨張 (1 文字 → 9 文字) や二重エンコーディングの落とし穴にも注意が必要です。URL の文字数を正確に把握したいときは、文字数カウントスでエンコード前後の長さを確認してみてください。