URL

Raport walidacji

Czym jest Walidator URL?

Wklejasz URL i dostajesz uporządkowany raport: czy jest poprawnie zbudowany, jak wygląda każdy komponent i na co warto uważać. Walidator przepuszcza URL przez natywny konstruktor URL przeglądarki — który implementuje standard WHATWG URL — i nakłada na to kontrole poszczególnych komponentów.

"Poprawny URL" to nie tylko taki, który się parsuje. URL w stylu http://10.0.0.5/admin?token=abc123 parsuje się bez problemu, ale ma trzy rzeczy, które prawdopodobnie chcesz zaznaczyć: http:// zamiast https://, literał IP jako host i token w query stringu. Walidator wyrzuca wszystkie trzy jako ostrzeżenia, niezależnie od werdyktu pass/fail. Reguły składni pochodzą z RFC 3986; kwestie nazewnictwa hostów z RFC 1034 i z doświadczenia operacyjnego.

Wynik to JSON, więc możesz go skierować potokiem do skryptu CI albo loga debugowego. Wszystko działa w przeglądarce — URL nigdy nie opuszcza twojej maszyny. Jeśli chcesz tylko rozbić URL na komponenty bez warstwy walidacji, użyj zamiast tego URL Parser. Międzynarodowe nazwy domen są obsługiwane zgodnie z regułami IDNA.

Jak używać Walidatora URL

Trzy kroki. Każdy odpowiada przyciskowi na tej stronie.

Wklej URL lub wczytaj przykład

Wrzuć URL do lewego panelu. Kliknij Przykład, aby załadować czysty, poprawnie zbudowany URL z parametrami zakodowanymi procentowo:

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

Walidator aktualizuje się w trakcie pisania. Spróbuj przypadków brzegowych: URL-e z http://, hosty z literałem IP, URL-e z danymi uwierzytelniającymi, hosty z pojedynczą etykietą (bez TLD), domeny Punycode. Każdy wyciąga inne ostrzeżenie.

Przeczytaj raport

Prawy panel pokazuje raport JSON z trzema polami najwyższego poziomu: isValid (URL w ogóle się sparsował), checks (status na komponent — protokół, hostname, port, pathname) oraz warnings (sygnały, które nie są błędami składni, ale prawdopodobnie cię obchodzą).

Kopiuj lub pobierz

Kliknij Kopiuj, aby wysłać raport JSON do schowka, albo Pobierz, aby zapisać jako .json. Minifikuj ścieśnia raport do jednej linii, jeśli potrzebujesz go do wpisu w logu.

Kiedy faktycznie tego użyjesz

Audyt pliku konfiguracyjnego przed deployem

Konfig twojego serwisu ma 40 URL-i — endpointy webhooków, callbacki OAuth, integracje z firmami trzecimi. Jeden ma wbudowane hasło z zapomnianego testu, dwa nadal wskazują hosty stagingowe na http://. Przepuszczenie ich pojedynczo przez walidator łapie wszystkie trzy przed wypuszczeniem na produkcję. Zależności od formatu URL pojawiają się też w specyfikacji OAuth 2.0 dla redirect URI.

Przegląd URL-i wpisanych przez użytkowników w formularzu

Użytkownik wpisuje pole "strona", które okazuje się example — bez protokołu, bez TLD, po prostu słowo. Albo https://192.168.1.5 — wygląda poprawnie, parsuje się poprawnie, ale niemal na pewno nie chcesz tego renderować jako linku w profilu. Walidator wyciąga oba: ostrzeżenie o brakującym TLD przy pierwszym, ostrzeżenie o literale IP przy drugim.

Diagnoza, dlaczego redirect zawodzi

Twój callback OAuth zwraca 400 z "invalid redirect_uri". URL wygląda dobrze w przeglądarce. Wklejasz go do walidatora i widzisz: w ścieżce jest dosłowna spacja, a twój dostawca auth porównuje stringi bajt po bajcie po kanonizacji. Ostrzeżenie ("path contains unencoded space") było odpowiedzią.

Wyłapanie rozjazdu Punycode vs Unicode

Spodziewałeś się zobaczyć w raporcie münchen.example.com, a zamiast tego widzisz xn--mnchen-3ya.example.com. To forma Punycode — to, co idzie po sieci — i walidator ją oznacza, żebyś wiedział, że oryginalne wejście miało znaki spoza ASCII. Przydatne, gdy użytkownik w bug reporcie skopiował i wkleił URL z domeny IDN.

Częste pytania

Co tutaj naprawdę znaczy "poprawny"?

Dwie warstwy. isValid: true oznacza, że konstruktor URL przeglądarki akceptuje wejście — czyli składnia jest poprawnie zbudowana zgodnie ze standardem WHATWG URL. warnings to coś osobnego: rzeczy składniowo poprawne, ale prawdopodobnie nie to, czego chcesz (niezabezpieczony protokół, literał IP, wbudowane dane uwierzytelniające, brak TLD itp.). URL może być poprawny i mimo to mieć ostrzeżenia.

Czy sprawdza, czy URL faktycznie się gdzieś rozwiązuje?

Nie — to wymagałoby żądania sieciowego, a to narzędzie działa w całości w twojej przeglądarce, bez wychodzących wywołań. Walidator sprawdza tylko składnię i powierzchowne heurystyki. Do sprawdzania osiągalności użyj curl -I albo dedykowanego narzędzia do uptime.

Dlaczego http://example.com jest oznaczony jako ostrzeżenie?

Bo w 2026 URL po jawnym tekście to prawie zawsze błąd — nowoczesne przeglądarki ostrzegają użytkowników przed wysłaniem formularzy przez http://, artykuł "why HTTPS matters" Google'a tłumaczy długą wersję, a domeny z preloadem HSTS w ogóle odmówią załadowania po HTTP. Ostrzeżenie ma charakter doradczy; jeśli naprawdę chcesz http:// (intranet legacy, lokalny dev), zignoruj je.

A co z URL-ami względnymi typu /api/orders?

Konstruktor URL potrzebuje URL-a bezwzględnego — bez bazy nie potrafi określić protokołu ani hosta. Walidator zwraca w takim wypadku isValid: false z czytelnym błędem. Aby zwalidować URL względny, najpierw poprzedź go bazą w stylu https://example.com.

Czy dane uwierzytelniające w URL-ach są zawsze złe?

Prawie zawsze. RFC 3986 §3.2.1 zaznacza, że dane uwierzytelniające w URL-ach są przestarzałe ze względów bezpieczeństwa. Lądują w historii przeglądarki, w logach dostępu serwera i w cache'ach proxy. Nowoczesne przeglądarki po cichu usuwają je przy wklejaniu ze schowka. Walidator je oznacza, żebyś miał wyraźny ślad, zanim wyciekną tam, gdzie nie powinny.

Czy zwraca uwagę na domeny IDN?

Tak — walidator notuje, czy hostname jest w postaci Punycode (xn--...) czy w czystym ASCII. Przeglądarki mogą pokazywać użytkownikom postać Unicode, a po sieci wysyłać postać Punycode, co jest źródłem ataków homograficznych IDN. Pokazanie Punycode to mały, ale przydatny sygnał.

Inne narzędzia URL i JSON

Walidacja to jedna operacja. Oto co naturalnie się z nią łączy: