URL 解析ツール
ブラウザー内蔵の URL パーサーでスキーム・ホスト・ポート・パス・クエリに分解。正規化で変わった箇所や RFC 3986 との違いを示し、パラメータも編集できます。
- ブラウザ内で処理
- データはブラウザ外に出ません
- 無料 · 登録不要
WeChat でスキャンしてシェア
例・詳しい説明・よくある質問 実際の出力つきの例、ほかのツールとの違い、よくある質問。
Yahoo! JAPAN の検索 URL を分解する
2026-10-01 に Yahoo! JAPAN のトップで「ラーメン 東京」を検索すると、アドレスバーは https://search.yahoo.co.jp/search?p=%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3+%E6%9D%B1%E4%BA%AC&fr=top_ga1_sa&ei=UTF-8&ts=120&aq=-1&oq=&at=&ai= になりました。貼り付けるとクエリパラメータは 8 個です。検索語の p は「ラーメン 東京」で、+ は空白としてデコードされます。ei は UTF-8、oq・at・ai は「=」の後が空の値です。注記は出ないので、ブラウザーがこの URL を手を加えずに受け付けたことがわかります。
Shift_JIS の古いリンク
Shift_JIS で作られた古い CGI のリンクでは、「ラーメン」が %83%89%81%5B%83%81%83%93 になります(Python の 'ラーメン'.encode('shift_jis') で確かめられます)。https://www.example.jp/cgi-bin/search.cgi?q=%83%89%81%5B%83%81%83%93 を貼り付けると、q は ���[���� と表示され、「UTF-8 ではない」の印が付きます。長音符の %5B は ASCII の [ と同じバイトなので、そこだけ読めてしまうのが Shift_JIS らしいところです。ブラウザーも URLSearchParams も UTF-8 でしか読まないため、この表示を見たらリンクを作った側の文字コードを確認してください。
日本語ドメインと全角入力
日本語 JP ドメイン名の情報サイト https://日本語.jp/ を貼り付けると、ブラウザーが送るホストは xn--wgv71a119e.jp(Punycode)です。ツールはホスト名の下に元の表記「日本語.jp」を並べます。漢字・ひらがな・カタカナ・ラテン文字の組み合わせは Unicode UTS #39 で正当な組み合わせとされているため、警告は出ません。
IME が全角のままだった https://example.jp/お問い合わせ も読めます。ホストの全角英字と全角ピリオドは国際化ドメイン名の規則で example.jp になり、パスの「お問い合わせ」は UTF-8 のバイト列にパーセントエンコードされます。どちらも注記に出ます。
ブラウザーとサーバーでホストが食い違う URL
ブラウザーは WHATWG URL Standard、サーバー側のライブラリは RFC 3986 に沿うことが多く、入力によってはホストが変わります。http://evil.example\@good.example/login では、ブラウザーは http や https のバックスラッシュをスラッシュとして読むので、ホストは evil.example です。RFC 3986 付録 B で分割すると、最後の @ より前はユーザー情報なので、ホストは good.example になります。2026-10-01 の確認では、Python 3.12 の urllib.parse.urlsplit() も curl 8.7.1 も good.example を使いました。http://0x7f.1/admin も、ブラウザーの IPv4 パーサーは 127.0.0.1 と読み、RFC 3986 では名前扱いです。ツールはどちらにも警告を出します。
パラメータを編集しても他は変わらない
クエリを URLSearchParams.toString() で組み直すと、すべてのパラメータが再エンコードされます。「=」のない flag は flag= に、%zz は %25zz に、上の Shift_JIS のバイト列は %EF%BF%BD の並びに置き換わり、元のリンクとして使えなくなります。このツールは編集・追加したパラメータだけをエンコードし、それ以外は元のバイト列のまま残します。項目の編集はブラウザー自身のセッター(url.port = … など)で行うので、ブラウザーが受け付けた結果がそのまま表示されます。
他のツールとの違い
2026-10-01 に、Bing の「URL パーサー」で上位に出る Web ToolBox に同じ 8 個の URL を貼り付けました。結果の各項目はブラウザーの URL パーサーと一致しますが、読み取り専用で編集はできません。example.com/path は「無効なURLです」とだけ表示され、理由もスキームの補い方も出ません。バックスラッシュの URL はホスト evil.example、0x7f.1 は 127.0.0.1、localhost:3000/api はプロトコル localhost: と表示され、どれにも注意書きはありません。なりすましドメイン раураl.com は Punycode のまま警告なし、UTF-8 として不正なパラメータは � と表示されるだけです。このツールは同じ結果に、なぜそうなったかの説明を添えます。
制限
- 結果はお使いのブラウザーのものです。Node.js 24 は web-platform-tests の URL テスト 896 件中 888 件に通ります。古いブラウザーでは細かな入力で結果が変わることがあります。
- Chromium(テストでは Chrome 152)は URL Standard が禁じるホストの一部を受け付けます。
http://exa mple.com/はホストexa%20mple.comと読まれますが、Node.js はこの URL を受け付けません。このときツールは標準では無効であることと問題の文字を示し、ブラウザーの読み方も表示します。 - RFC 3986 の欄は付録 B の正規表現による分割と文字のチェックだけです。特定のライブラリの動きを再現するものではないので、サーバー側は実際の URL で確認してください。
- Public Suffix List は持っていないため、
shop.example.co.jpをサブドメインと登録ドメインに分けることはしません。 - なりすましの警告は、文字種の混在と、ラテン文字に似たキリル文字・ギリシャ文字だけでできたラベルが対象です。
- クエリパラメータの表に出すのは先頭 500 個までです。
値を 1 つエンコード・デコードするなら URL エンコード / デコード、ホストの DNS レコードを見るなら DNS 確認ツール、OAuth の認可 URL を作るなら PKCE ジェネレーター、ページが実際に送った URL を調べるなら HAR ファイル アナライザー が使えます。
FAQ
JavaScript の new URL() と同じ結果になりますか?
同じです。このツールはブラウザーの URL パーサー(new URL() の実体、WHATWG URL Standard 準拠)をそのまま使います。加えて RFC 3986 付録 B の正規表現でも分割し、ホストの読み方が食い違うときは警告します。
example.com/path がエラーになるのはなぜですか?
URL には https:// などのスキームが必要です。スキームがないと new URL() は例外を投げるので、ツールは理由を示し、「https://example.com/path として解析」ボタンを出します。/api/users や ../img/logo.png のような相対 URL は「ベース URL」に基準となるページの URL を入れてください。
パラメータが「UTF-8 ではない」と表示されます。
パーセントエンコードが UTF-8 以外、たとえば Shift_JIS で作られています。ブラウザーと URLSearchParams は UTF-8 としてしか読まないため、読めないバイトは �(U+FFFD)になります。ツールも同じ表示をして印を付け、元のバイト列は「元の表記」に残します。
全角で入力した URL はどう扱われますか?
ホスト部分の全角英数字と全角ピリオドは、国際化ドメイン名の規則(UTS #46)で半角に変換されます。ツールは「ホストが正規化された」と表示します。スキームの「https」や全角コロンは変換されないため、URL として読めません。
入力した URL は送信・保存されますか?
されません。解析はこのタブの中でブラウザーの URL と TextDecoder を使って行い、ページが URL を含むリクエストを送ることも、保存することもありません。URL 内のパスワードは「表示」を押すまで伏せ字です。