URL

Valideringsrapport

Hvad er URL-validatoren?

Du indsætter en URL og får en struktureret rapport tilbage: er den velformet, hvordan ser hver komponent ud, og hvad bør du holde øje med. Validatoren sender URL'en gennem browserens indbyggede URL-konstruktor — som implementerer WHATWG URL-standarden — og lægger derefter kontroller pr. komponent ovenpå.

En "gyldig URL" er ikke bare én, der parses. En URL som http://10.0.0.5/admin?token=abc123 parses fint, men har tre ting, du sandsynligvis vil have flagget: http:// i stedet for https://, en IP-literal som vært og en token i query-strengen. Validatoren får alle tre frem som advarsler, adskilt fra pass/fail-kontrollen. De underliggende syntaksregler kommer fra RFC 3986; overvejelser om værtsnavne kommer fra RFC 1034 og driftserfaring.

Output er JSON, så du kan pipe det ind i et CI-script eller en debug-log. Alt kører i din browser — URL'en forlader aldrig din maskine. Vil du blot opdele URL'en i komponenter uden valideringslaget, brug URL Parser i stedet. Internationaliserede domænenavne håndteres efter IDNA-reglerne.

Sådan bruger du URL-validatoren

Tre trin. Hvert trin svarer til en knap på denne side.

Indsæt en URL eller indlæs eksemplet

Slip en URL i venstre panel. Klik på Eksempel for at indlæse en ren, velformet URL med procent-kodede query-parametre:

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

Validatoren opdateres mens du skriver. Prøv kant-tilfælde: http://-URLs, IP-literal-værter, URLs med legitimationsoplysninger, single-label-værter (uden TLD), Punycode-domæner. Hver enkelt fremkalder en anden advarsel.

Læs rapporten

Højre panel viser en JSON-rapport med tre top-felter: isValid (URL'en parsede overhovedet), checks (status pr. komponent — protokol, hostname, port, pathname) og warnings (rådgivende punkter, der ikke er syntaksfejl, men som du nok bekymrer dig om).

Kopiér eller download

Klik på Kopiér for at sende JSON-rapporten til udklipsholderen, eller Download for at gemme den som .json. Minificer presser rapporten på én linje, hvis du har brug for det til en log-linje.

Hvornår du faktisk ville bruge det

Audit af en config-fil før deploy

Din service-config har 40 URLs — webhook-endpoints, OAuth-callbacks, tredjepartsintegrationer. Én har et indlejret password fra en glemt test, to peger stadig på http://-stagingværter. At køre dem én ad gangen gennem validatoren fanger alle tre, før de går live. Krav til URL-format dukker også op i OAuth 2.0-specifikationen for redirect-URI'er.

Gennemgang af brugerindsendte URLs i en formular

En bruger indsender et "website"-felt, der viser sig at være example — ingen protokol, ingen TLD, bare ét ord. Eller https://192.168.1.5 — ser gyldig ud, parser gyldig, men du vil næsten helt sikkert ikke rendere det som et profil-link. Validatoren får begge frem: TLD-mangler-advarsel på den første, IP-literal-vært-advarsel på den anden.

Diagnosticer hvorfor en redirect fejler

Din OAuth-callback returnerer 400 med "invalid redirect_uri." URL'en ser fin ud i browseren. Du indsætter den i validatoren og opdager det: stien indeholder et bogstaveligt mellemrum, og din auth-udbyder sammenligner strenge byte for byte efter kanonisering. Advarslen ("path contains unencoded space") var svaret.

At opdage en Punycode-vs-Unicode-uoverensstemmelse

Du forventede at se münchen.example.com i rapporten og så i stedet xn--mnchen-3ya.example.com. Det er Punycode-formen — det, der sendes over ledningen — og validatoren markerer den, så du ved, at det oprindelige input havde ikke-ASCII-tegn. Nyttigt når brugeren i en bug-rapport har kopieret-indsat en URL fra et IDN-domæne.

Hyppige spørgsmål

Hvad betyder "gyldig" egentlig her?

To lag. isValid: true betyder, at browserens URL-konstruktor accepterer inputtet — altså at syntaksen er velformet ifølge WHATWG URL-standarden. warnings er adskilt: ting der er syntaktisk gyldige, men nok ikke det du vil have (usikkert protokol, IP-literal, indlejrede legitimationsoplysninger, manglende TLD osv.). En URL kan være gyldig og stadig have advarsler.

Tjekker det om URL'en faktisk resolver til noget?

Nej — det ville kræve et netværkskald, og dette værktøj kører helt i din browser uden udgående kald. Validatoren tjekker kun syntaks og overfladiske heuristikker. Til tilgængelighedstjek, brug curl -I eller et dedikeret uptime-værktøj.

Hvorfor markeres http://example.com som advarsel?

Fordi en klartekst-URL i 2026 næsten altid er en fejl — moderne browsere advarer brugere før formularer sendes over http://, Googles "why HTTPS matters" dækker den lange version, og HSTS-preloadede domæner nægter helt at indlæse over HTTP. Advarslen er rådgivende; mener du virkelig http:// (legacy-intranet, lokal dev), så ignorer den.

Hvad med relative URLs som /api/orders?

URL-konstruktoren har brug for en absolut URL — uden en base kan den ikke afgøre protokol eller vært. Validatoren returnerer i det tilfælde isValid: false med en klar fejl. For at validere en relativ URL, sæt først en base som https://example.com foran.

Er legitimationsoplysninger i URLs altid forkert?

Næsten altid. RFC 3986 §3.2.1 bemærker, at legitimationsoplysninger i URLs er udfaset af sikkerhedsårsager. De ender i browser-historik, i server-access-logs og i proxy-caches. Moderne browsere fjerner dem stille fra udklipsholder-indsætninger. Validatoren markerer dem, så du har et eksplicit spor, før de lækker et sted, hvor de ikke skulle.

Bekymrer den sig om IDN-domæner?

Ja — validatoren noterer, om hostnavnet er i Punycode-form (xn--...) eller ren ASCII. Browsere kan vise Unicode-formen til brugere, mens de sender Punycode-formen over ledningen, hvilket er kilden til IDN-homografangreb. At fremhæve Punycoden er et lille, men nyttigt signal.

Andre URL- og JSON-værktøjer

Validering er én operation. Her er hvad der naturligt passer sammen med det: