URL 長の上限と日本語の URL エンコード膨張
一言まとめ
日本語 1 文字は URL エンコードで 9 文字(UTF-8 3 バイト × `%XX`)に膨らむ。ブラウザの URL 上限は Safari 約 80KB / Firefox 約 64KB で、クエリに本文を載せて外部サービスへ遷移する設計では 16,000 文字程度を切り替え閾値に置くと安全側。
目次 6 sections
調査時点: 2026-08。ある PWA で、溜めたテキストをクエリ文字列(?q=)に載せて外部サービスへ遷移する機能を作ったときの検討。
日本語は 9 倍に膨らむ
UTF-8 で日本語 1 文字は 3 バイト。URL エンコードすると各バイトが %XX の 3 文字になるので、1 文字が 9 文字になる。ASCII の英数字はエンコード不要なので膨らまない。
日本語主体の本文を URL に載せると、見た目の文字数の約 9 倍の長さの URL になる。
ブラウザの URL 上限
| ブラウザ | 上限の目安 |
|---|---|
| Safari | 約 80KB |
| Firefox | 約 64KB |
| Chrome | 2MB 程度(実用上はサーバ側の制限が先に効く) |
遷移先のサーバやプロキシが別途上限を持つことも多いので、ブラウザの値だけを根拠にしない。
閾値の置き方
上記の PWA では、URL エンコード後 16,000 文字を「クエリに載せる方式」と「ファイルを添付させる方式」の切り替え点にした。根拠は次のとおり。
- 1 項目あたり約 190 文字(エンコード後)で、約 84 項目まで収まる。実データ(3 日で 20〜50 項目)の大半が通る。
- Safari / Firefox の上限に対して十分な余裕がある。
- 定数として 1 か所に置き、使いながら調整できるようにする。
書式変更で URL 長が伸びることがある(Markdown の継続行に 2 スペースを足したとき、46 項目で 15,099 → 15,285 文字)。閾値の余裕が数 % しかないときは、閾値を上げるか書式を見直す。
遷移前の確認について
遷移先が ?q= を自動送信する場合、その挙動はこちらから止められない。止められないものに確認ダイアログを出しても結果は変わらないので、代わりに N KB · URL 遷移で送信 のように何が起きるかを事前に表示し、1 タップで遷移させる。やり直しのコストが低い操作なら、この形で足りる。
関連
更新履歴
- 2026-08-29: 初版(ローカル調査ノート)
- 2026-10-17: Wiki へ移植、概念ページとして再構成
同じトピック — Web
- 単一画面の Canvas ツールのスタック選定(vanilla TS / Svelte / Preact と PWA ツーリング)
- DAM カラオケ検索(clubdam)の挙動と制約
- Core Web Vitals と画像最適化
- favicon の最小構成(SVG + ICO + apple-touch-icon + manifest)
- フロントエンドのフレームワークとツールの動き(2025)
- HTML-in-Canvas API
- HTML-in-Canvas の実現性(a11y・性能・セットアップ・シェーダー)
- iOS Safari で canvas の画像を保存させる(download 属性 / Web Share / 長押し)
- 日本語 Web フォントのライセンスとサブセット化
- 個人サイトのライブウィジェットと外部 API の制限
- モダン CSS / Web API の対応状況(2025-2026)
- OPFS(Origin Private File System)
- Google Places API のキーの守り方(ブラウザ露出 vs サーバ中継)
- iOS の PWA 制限
- 機能別 React / TS ライブラリ対応表(2026-04 時点)
- 書き出すテキストファイルの UTF-8 BOM と Markdown 継続行
- 縦書き Web の実装(writing-mode・ルビ・圏点・縦中横・禁則)
- PWA の Web Share Target(Android)の実測と落とし穴
- WebAssembly(Wasm)
- YouTube oEmbed で動画タイトルとチャンネル名を取る