URL

検証レポート

URLバリデーターとは？

URLを貼り付けると構造化されたレポートが返ってきます。形式は正しいか、各コンポーネントはどう見えるか、何に気をつけるべきか。バリデーターはURLをブラウザネイティブのURLコンストラクタに通します — これはWHATWG URL Standardを実装しており、その上にコンポーネント別のチェックを重ねています。

「有効なURL」とは、ただパースが通るURLのことではありません。http://10.0.0.5/admin?token=abc123のようなURLは問題なくパースできますが、おそらくフラグを立てたいことが3つあります。https://ではなくhttp://であること、ホストがIPリテラルであること、クエリ文字列にトークンが含まれていることです。バリデーターはこの3つを、合否チェックとは別に警告として出します。基礎となる構文ルールはRFC 3986から、ホスト命名に関する考慮事項はRFC 1034と現場の運用経験から来ています。

出力はJSONなので、CIスクリプトやデバッグログにそのまま流し込めます。すべてブラウザ内で動作します — URLがマシンの外に出ることはありません。検証レイヤーなしでURLをコンポーネントに分解したいだけなら、代わりにURLパーサーを使ってください。国際化ドメイン名はIDNAルールに従って処理されます。

URLバリデーターの使い方

3ステップ。それぞれがこのページのボタンに対応しています。

URLを貼り付けるかサンプルを読み込む

左パネルにURLをドロップします。サンプルをクリックすると、パーセントエンコードされたクエリパラメータを含む、整ったURLが読み込まれます：

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active

バリデーターは入力に応じて更新されます。エッジケースを試してみてください：http:// URL、IPリテラルホスト、認証情報付きURL、シングルラベルホスト（TLDなし）、Punycodeドメイン。それぞれが異なる警告を出します。

レポートを読む

右パネルには3つのトップレベルフィールドを持つJSONレポートが表示されます：isValid（URLがそもそもパースできたか）、checks（コンポーネント別ステータス — プロトコル、ホスト名、ポート、パス名）、warnings（構文エラーではないが、たぶん気になる助言的な事項）。

コピーまたはダウンロード

コピーをクリックするとJSONレポートをクリップボードに送り、ダウンロードで.jsonとして保存できます。圧縮はログエントリ用に必要なら、レポートを1行に詰めます。

実際に使う場面

デプロイ前にconfigファイルを監査する

サービスのconfigには40個のURLが入っています — webhookエンドポイント、OAuthコールバック、サードパーティ統合。1つは忘れられたテストのパスワードが埋め込まれていて、2つはhttp://のステージングホストを指したままです。1つずつバリデーターに通せば、出荷前に3つすべてキャッチできます。URLフォーマットへの依存は、リダイレクトURIに関するOAuth 2.0仕様にも現れます。

フォームでユーザー送信のURLをレビューする

ユーザーが「ウェブサイト」フィールドに送ってきたのがexample — プロトコルなし、TLDなし、ただの単語。あるいはhttps://192.168.1.5 — 一見有効、パースも通る、でもプロフィールリンクとしてレンダリングしたくないのは確かです。バリデーターは両方を浮かび上がらせます：1つ目にはTLD欠落警告、2つ目にはIPリテラルホスト警告。

リダイレクトが失敗する原因を診断する

OAuthコールバックが「invalid redirect_uri」で400を返しています。ブラウザではURLは正常に見えます。バリデーターに貼り付けると見つかります：パスにリテラルスペースが入っていて、認証プロバイダーは正規化後にバイト単位で文字列を比較しています。警告（「path contains unencoded space」）が答えだったわけです。

Punycode vs Unicodeの不一致を見つける

レポートにmünchen.example.comを期待していたのに、代わりにxn--mnchen-3ya.example.comが出てきました。これはPunycode形式 — 通信線で送られる形 — で、バリデーターはこれをフラグして元の入力に非ASCII文字が含まれていたことを知らせます。バグレポートでユーザーがIDNドメインからURLをコピペしたときなどに便利です。

よくある質問

ここでの「有効」とは実際にどういう意味ですか？

2層あります。isValid: trueは、ブラウザのURLコンストラクタが入力を受け入れたという意味 — つまり構文がWHATWG URL Standardに従って正しい形式であることを意味します。warningsは別物で、構文的には有効だが、おそらく望むものではない事柄（安全でないプロトコル、IPリテラル、埋め込み認証情報、TLD欠落など）です。URLは有効でありながら警告を持つことがあります。

URLが実際に何かに解決されるかチェックしますか？

いいえ — それはネットワークリクエストが必要で、このツールはブラウザ内で完結し外部呼び出しは一切ありません。バリデーターは構文と表面的なヒューリスティックだけをチェックします。到達性チェックにはcurl -Iや専用のアップタイムツールを使ってください。

なぜhttp://example.comが警告として出るのですか？

2026年において平文URLはほぼ常に間違いだからです — モダンブラウザはhttp://でフォーム送信する前にユーザーに警告し、Googleの「why HTTPS matters」が長い解説を提供しており、HSTSプリロード済みドメインはHTTPでは一切ロードを拒否します。警告は助言です。本当にhttp://を意図しているなら（レガシーなイントラネット、ローカル開発）、無視してかまいません。

/api/ordersのような相対URLはどうなりますか？

URLコンストラクタは絶対URLが必要です — ベースなしではプロトコルやホストを判定できません。バリデーターはその場合、明確なエラー付きでisValid: falseを返します。相対URLを検証するには、まずhttps://example.comのようなベースを前置してください。

URLに認証情報を入れるのは常に間違いですか？

ほぼそうです。RFC 3986 §3.2.1はセキュリティ上の理由でURL内の認証情報が非推奨であると述べています。それらはブラウザ履歴、サーバーアクセスログ、プロキシキャッシュに残ります。モダンブラウザはクリップボードからの貼り付け時に静かにそれらを除去します。バリデーターはそれらをフラグして、漏れてはいけない場所に漏れる前に明示的な記録を残せるようにします。

IDNドメインに対応していますか？

はい — バリデーターはホスト名がPunycode形式（xn--...）か純粋なASCIIかを記録します。ブラウザはユーザーにUnicode形式を表示しつつ、通信線ではPunycode形式を送信することがあり、これがIDNホモグラフ攻撃の元になっています。Punycodeを浮かび上がらせるのは小さいけれど有用なシグナルです。

その他のURL & JSONツール

検証は1つの操作です。これと自然に組み合わさるツールがこちら：