URLの最大長というものは存在しません。URIの構文を定めた標準であるRFC 3986は、そのような上限を一切定めていません - 合法な文字は何か、URLはどのように組み立てられるかを記述するだけで、それ以上には踏み込まないのです。実際に直面するのは、互いに無関係な制限の連鎖です。ブラウザのアドレスバー、その先にあるWebサーバー、両者の間に立つプロキシ、リンクを開くメールクライアント、あるいはこれから印刷しようとしているQRコードです。それぞれが独自の上限を課しており、URLの実際の最大長は、その中で最も低い上限によって決まります。3,000文字のURLを送り出せば、Chromeでは問題なく表示される一方で、初期設定のサーバーには拒否され、Outlookでは4行にわたって折り返されて届くかもしれません。どれもバグではありません。長さについてあえて何も定めなかった仕様がもたらす、実務上の当然の帰結です。
ここから4つのことが導かれます。仕様が何を定め、何を定めていないか。有名な2,083文字という数字がどこから来て、意味を失って何年も経った今もなおチェックリストに残り続けているのはなぜか。リンクがブラウザを離れた瞬間に実際に効いてくる制限とは何か。そして、長くなりすぎたURLにどう対処すべきか、です。これらすべてを実際の通信の中でショートナーがどう扱っているかについては、URL短縮サービスはどう動くのかを参照してください。
RFC 3986がURLの長さについて実際に述べていること
RFC 3986はURIの一般的な構文、スキーム、権限部分、パス、クエリ、フラグメントを定義していますが、それぞれがどこまで長くなり得るかについては何も述べていません。書き漏らしたのではなく、意図的に述べていないのです。セクション3の文法は、少数の生成規則の組み合わせでURIを組み立てますが、それらの規則のどこにも、規則を繰り返せる回数の上限はありません。構文だけを見れば、パスセグメントは1文字でも10万文字でも構いません。長いURLも、まったく合法なURLです。
RFCが課している唯一の制限は間接的なものです。URLの権限部分にはホスト名が含まれており、DNSはホスト名の完全修飾ドメイン名としての長さを、URIの文法が許す範囲よりもずっと低く制限しています。Chromiumのエンジニアリングドキュメントは、その上限を合計253文字、1ラベルあたり63文字としています。パス、クエリ文字列、フラグメントには、標準のどこにもこうした制約はありません。
仕様の側から言えるのはここまでです。実際に直面するURLの文字数制限は、URLを読み取るソフトウェアから来るものであり、URLの形式そのものから来ることは決してありません。
2,083という数字はどこから来たのか、そして今のブラウザはどうなのか
URLの長さに関するガイドラインをどこかで目にしたことがあるなら、そこには2,083文字という数字が書かれていたはずです。その数字自体は実在しますが、特定の1つのブラウザ、特定の時代、特定のコードパスに属するものです。Internet ExplorerのWinINETネットワーキングライブラリはINTERNET_MAX_URL_LENGTHを2083文字と定義しており、Microsoft自身によるこの制限についての技術解説によれば、アドレスバー自体はそれより1文字低い2047文字に制限されていました。この上限は10年以上にわたってWebトラフィックの大半を支配していたため、誰もがこれに合わせて設計するようになり、その習慣は、それが由来するブラウザ自体よりも長生きしています。
現代のブラウザはそのようには動作しません。Chromeのドキュメントは、UIのフィールドを守るためではなくプロセス間通信の問題を避けるために設けられた、2メガバイトという内部制限を明記しており、それとは別に、オムニボックスが実際に表示する範囲を制限する、はるかに小さい約32キロバイト(デスクトップの場合)という定数があります。FirefoxとSafariも同様に寛容で、手作業で組み立てる程度の長さのURLでつまずくことはまずありません。現代のブラウザが長いURLを拒否したことが原因の本番障害を、私は一度もデバッグしたことがありません。私がこれまで追跡した長いURL絡みのバグは、すべてブラウザより先の段階で発生していました。
実際に効いてくる現実の制限
URLが実際に通過する場所を並べてみると、すぐにあるパターンが見えてきます。最も厳しい制限が、ブラウザ側にあることはめったにない、ということです。
- サーバーのリクエストラインは、HTTPリクエストの最初の行の一部としてURLを読み取り、その行には専用のバッファがあります。これを超えると、サーバーはルートを解析することすらしません - アプリケーションのコードが動く前に、接続そのものを拒否します。
- メールクライアントは、あふれた分の扱いがそれぞれ異なります。Outlookは長いプレーンテキストのURLを切り詰めるのではなく複数行に折り返します。見た目は悪いですが、クリックはできます。一方、一部のWebメールクライアントや転送ゲートウェイはそこまで寛容ではなく、リンクをばっさり切り落とします。
- テキストメッセージの中のリンクは、本文と同じ文字数の予算を奪い合います。SMSマーケティング向けのリンクは160文字のセグメントの中に収まる必要があり、長いURLがあるだけで1セグメントで済むはずのテキストが2セグメントになってしまうことがあります。キャリアはセグメント数によって課金やフィルタリングの扱いを変えています。
- QRコードは長いURLを切り詰めることはなく、ただ密度が上がるだけです。QRコードに必要なサイズは、エンコードさせる情報量にそのまま比例して決まり、トラッキングパラメータを詰め込んだURLはコードのバージョンを1つか2つ押し上げ、スキャンできる距離を縮めてしまいます。
- スプレッドシートのハイパーリンク関数は、リンク引数に独自の厳格な文字数制限を課しており、その上限は典型的なタグ付きURLよりもかなり短めです。これを超えたリンクは何のエラーも出さずに失敗します - セルの表示は正常に見えても、リンク自体は機能しません。
- 広告プラットフォームは、遷移先URLのフィールドに、技術的な制約ではなく独自のプラットフォームルールとして固定の長さの上限を設けており、キャンペーン担当者は、ブラウザなら何の問題もなく開くはずのURLが保存ボタンで拒否されて初めて、それに気づくことになります。
これらの制限はお互いに一切連携していません。あるURLがサーバーのリクエストラインをクリアしても、3つ先の部署のスプレッドシートで機能しなくなることは十分にあり得ます。
サーバーとプロキシのリクエストライン制限
サーバーのケースは、見た目だけの不具合ではなく実際のエラーコードを生む唯一のケースなので、それだけを取り上げる価値があります。414 Request-URI Too Longは、URIがサーバーの解釈可能な長さを超えているためにリクエストの処理を拒否するときにサーバーが返すレスポンスです - これは、その瞬間にリクエストラインを読んでいるソフトウェアによって、ホップ単位で課されるURLサイズの上限です。
経路上のすべてのサーバーとプロキシが、それぞれ独自バージョンのこの制限を課しています。ApacheのLimitRequestLineディレクティブは、初期設定でリクエストライン全体に対して8,190バイトまでを許可しますが、これにはURL自体だけでなくメソッドやプロトコルバージョンも含まれます。nginxはリクエストヘッダーを、large_client_header_buffersで制御される固定バッファ、初期設定で8キロバイトに読み込み、そこに収まらないリクエストラインはルートが一致するより前に414を返されます。どちらの手前にあるロードバランサーやCDNも、しばしばさらに別の第3の制限を課しているため、あるURLがオリジンサーバーの設定をクリアしても、その1つ手前のホップで拒否されることがあります。
すべてのホップを自分で制御できない場合、そしてある程度の規模の会社になれば誰もそれを完全には制御できませんが、安全な進め方は、設定ファイルの中で見つけた最も寛容な値ではなく、共通して見られる最も厳しい初期設定に合わせて設計することです。
リクエストの解析を自前で書くのではなく、リダイレクト層そのものを構築してしまうのが、地味だけれど確実な解決策です。ElidoのAPIは、妥当な長さであればどんな遷移先も受け付け、サイズが変わることのない短縮リンクを返します。そのため、サーバーのリクエストラインの上限は、統合のたびに個別に対処すべき問題ではなく、エッジで一度だけ設定しておけば済むものになります。
配信する前にURLの実際の長さを測る方法
測定すべきものは文字数だけであり、バウンスレポートが届いてからではなく、URLをキャンペーンに投入する前に確認しておく価値があります。
printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c
これで、書かれたとおりのURLのバイト長がわかります。これを少しややこしくする要素が2つあります。1つ目は、パーセントエンコードされた文字は見た目以上にコストがかかるということです。クエリの値の中にあるアクセント付きの文字や絵文字は、エンコード後に6文字以上に膨らむことがあるため、エンコードする前ではなく後の状態で測定してください。2つ目は、UTMパラメータがたいていの場合、URLの中で最も速く肥大化する部分だということです。キャンペーン、ソース、メディア、コンテンツといったタグをいくつか並べるだけで、もともと短かったパスに数百文字が追加されることがあり、URLが気づかないうちに長くなりすぎたときにまず確認すべき場所でもあります。
以前は機能していたリンクが突然機能しなくなったら、他の死んだリンクと同じ手順で調査してください。短縮リンクが機能しない場合では、遷移先を直接確認する方法を解説しており、これはまさに、トラッキングパラメータが1つずつ積み重なってサーバーの上限を超えてしまったURLを見つけ出す方法でもあります。
URLが長すぎるときにすべきこと
実際に効く解決策は2つしかなく、どの制限に引っかかったかにかかわらず、その2つは変わりません。
1つ目は、URLを短縮することです。短縮リンクは固定長のポインタです - 遷移先やそのトラッキングパラメータがどれだけ長くなっても、スラッグの長さは変わりません。それらの情報はすべてサーバー側に置かれ、リンク自体に運ばせるのではなく、クリックのたびに参照されるからです。これにより、QRコードの密度の問題、SMSのセグメントの問題、スプレッドシートの問題を一度に解決できます。この3つはいずれも、最終的にどこへたどり着くかの長さではなく、リンクそのものの文字数を気にしているからです。
2つ目は、状態をクエリ文字列から完全に切り離すことです。URLを長くしている原因が、正真正銘のトラッキングパラメータではなくセッションデータやカートの中身のかたまり、あるいは長いフィルタ条件のリストなのであれば、そのデータはたいていの場合、アドレスバーに書き出すのではなく、サーバー側で不透明なIDの裏に隠しておくべきものです。/checkout?session=a1b2c3d4と書かれたURLは、すべてのSKUと数量を書き出した/checkout?items=...よりも長く生き延びますし、測るべき長さがそもそも残っていないため、この記事で挙げたすべての制限を一度に回避できます。
どちらの解決策も、行き着く先は同じです。URLの長さを、たまたま積み上がったパラメータの数の結果ではなく、設計上の意思決定として扱うことです。
コーナーストーンシリーズを読む
この記事はエンジニアリングクラスターに属しています。短縮リンクの向こう側で何が起きているかについては、URL短縮サービスはどう動くのかがルックアップ自体を解説し、URLリダイレクトの種類が遷移先が見つかった後のステータスコードについて解説しています。
ブログの関連記事
よくある質問
URLの最大長はどれくらいですか。
Web自身の標準で定められた上限はありません。RFC 3986はURLの構文を定めていますが、その長さを制限することは一切なく、実際の上限は、経路上のどのシステムが最も厳しい制限を課しているかによって決まります。ブラウザ、サーバー、メールクライアント、あるいはQRコードのいずれかです。URLをおおよそ2,000文字未満に収めておけば、こうしたシステムのほぼすべてを一度にクリアできるため、どの仕様もそれを要求していないにもかかわらず、この数字は安全な目安として使われ続けています。
なぜURLは2,083文字までと言われるのですか。
この数字は、Internet ExplorerのWinINETネットワーキングライブラリに由来します。このライブラリはINTERNET_MAX_URL_LENGTHを2083文字と定義しており、ブラウザ自体のアドレスバーはそれより1文字低い2047文字に制限されていました。何年もの間、Webトラフィックの大半をこの制限が支配していたため、それが既定の安全な前提として広まり、この数字を引用する習慣は、それが由来するブラウザ自体よりも長生きしています。
ChromeなどのモダンなブラウザにおけるURLの最大長はどれくらいですか。
Chrome自身のドキュメントは、アドレスバーを保護するためではなくプロセス間通信の問題を避けるために設けられた、2メガバイトという内部制限を明記しており、それとは別に、オムニボックスが実際に表示する範囲を制限する定数として、デスクトップ環境ではおおよそ32キロバイトという値があります。FirefoxやSafariも同様に寛容です。実際のところ、現行のブラウザが最初にぶつかる制限になることはありません。
URLが長すぎるとどうなりますか。
どのような失敗になるかは、どのシステムが拒否したかによって完全に決まります。サーバーやプロキシは通常414 Request-URI Too Longというレスポンスを返し、アプリケーションのコードは一切実行されません。メールクライアントはリンクを複数行に折り返すか、あるいは切り詰めます。QRコードはただ密度が上がり、遠くからスキャンしづらくなるだけです。スプレッドシートのセルは正常に表示されたまま、裏側のリンクだけが静かに機能しなくなることがあります。
SEOの観点では、URLはどのくらいの長さにすべきですか。
長さそのものはランキング要因ではありませんが、不要なパラメータが詰め込まれたURLは、重複コンテンツやサイト構造の分かりにくさなど、検索エンジンが実際に気にする問題の兆候であることがよくあります。実務的には、URLを2,000文字よりも十分に短く保っておけば、ここまで挙げた互換性の問題は避けられますし、パスを短く分かりやすく保つことは、SEOというよりもユーザビリティ上の判断です。
URLの長さを確認するにはどうすればよいですか。
測定は、エンコードする前ではなく後の文字数で行ってください。プレーンなASCIIの範囲外にある文字は、パーセントエンコードされた時点で長くなるためです。ターミナルで1行、printf '%s' 'your-url' | wc -cと実行するだけで、これから送り出そうとしているURLの正確なバイト長、つまりサーバーやメールクライアント、QRコード生成ツールが目にするのと同じ数字がわかります。
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件