URL

Valideringsrapport

Hva er URL-validatoren?

Du limer inn en URL og får tilbake en strukturert rapport: er den velformet, hvordan ser hver komponent ut, og hva bør du følge med på. Validatoren kjører URL-en gjennom nettleserens innebygde URL-konstruktør — som implementerer WHATWG URL-standarden — og legger så kontroller per komponent oppå.

En "gyldig URL" er ikke bare en som parses. En URL som http://10.0.0.5/admin?token=abc123 parses helt fint, men har tre ting du sannsynligvis vil ha flagget: http:// i stedet for https://, en IP-literal som vert og en token i query-strengen. Validatoren får alle tre frem som advarsler, atskilt fra pass/fail-sjekken. De underliggende syntaksreglene kommer fra RFC 3986; vurderingene rundt vertsnavn fra RFC 1034 og driftserfaring.

Output er JSON, så du kan pipe det inn i et CI-skript eller en debug-logg. Alt kjører i nettleseren din — URL-en forlater aldri maskinen din. Vil du bare bryte URL-en ned i komponenter uten valideringslaget, bruk URL Parser i stedet. Internasjonaliserte domenenavn håndteres etter IDNA-reglene.

Slik bruker du URL-validatoren

Tre steg. Hvert steg tilsvarer en knapp på denne siden.

Lim inn en URL eller last inn eksemplet

Slipp en URL i venstre panel. Klikk Eksempel for å laste inn en ren, velformet URL med prosent-kodede query-parametre:

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

Validatoren oppdateres mens du skriver. Prøv kanttilfeller: http://-URL-er, IP-literal-verter, URL-er med påloggingsdetaljer, single-label-verter (uten TLD), Punycode-domener. Hver av dem fremkaller en ulik advarsel.

Les rapporten

Høyre panel viser en JSON-rapport med tre topp-felt: isValid (URL-en parset i det hele tatt), checks (status per komponent — protokoll, hostname, port, pathname) og warnings (rådgivende punkter som ikke er syntaksfeil, men som du sannsynligvis bryr deg om).

Kopier eller last ned

Klikk Kopier for å sende JSON-rapporten til utklippstavlen, eller Last ned for å lagre den som .json. Minifiser presser rapporten ned på én linje hvis du trenger den til en log-linje.

Når du faktisk ville brukt dette

Revidere en config-fil før deploy

Service-configen din har 40 URL-er — webhook-endepunkter, OAuth-callbacks, tredjepartsintegrasjoner. Én har et innebygd passord fra en glemt test, to peker fortsatt på http://-stagingverter. Å kjøre dem én og én gjennom validatoren fanger alle tre før de går live. Krav til URL-format dukker også opp i OAuth 2.0-spesifikasjonen for redirect-URI-er.

Gjennomgå URL-er som brukere har sendt inn i et skjema

En bruker sender inn et "nettsted"-felt som viser seg å være example — ingen protokoll, ingen TLD, bare ett ord. Eller https://192.168.1.5 — ser gyldig ut, parser gyldig, men du vil nesten helt sikkert ikke rendre det som en profil-lenke. Validatoren får frem begge: TLD-mangler-advarsel på den første, IP-literal-vert-advarsel på den andre.

Diagnostisere hvorfor en redirect feiler

OAuth-callbacken din returnerer 400 med "invalid redirect_uri". URL-en ser fin ut i nettleseren. Du limer den inn i validatoren og oppdager det: stien har et bokstavelig mellomrom, og auth-leverandøren din sammenligner strenger byte for byte etter kanonisering. Advarselen ("path contains unencoded space") var svaret.

Fange en Punycode-vs-Unicode-uoverensstemmelse

Du forventet å se münchen.example.com i rapporten og så i stedet xn--mnchen-3ya.example.com. Det er Punycode-formen — det som sendes over linjen — og validatoren markerer den, så du vet at det opprinnelige innspillet hadde ikke-ASCII-tegn. Nyttig når brukeren i en feilrapport har kopiert-limt inn en URL fra et IDN-domene.

Vanlige spørsmål

Hva betyr "gyldig" egentlig her?

To lag. isValid: true betyr at nettleserens URL-konstruktør aksepterer input-en — altså at syntaksen er velformet etter WHATWG URL-standarden. warnings er noe annet: ting som er syntaktisk gyldige, men sannsynligvis ikke det du vil ha (usikker protokoll, IP-literal, innebygde påloggingsdetaljer, manglende TLD osv.). En URL kan være gyldig og likevel ha advarsler.

Sjekker den om URL-en faktisk peker til noe?

Nei — det ville krevd et nettverkskall, og dette verktøyet kjører helt i nettleseren din uten utgående kall. Validatoren sjekker bare syntaks og overflatisk heuristikk. For tilgjengelighetssjekker, bruk curl -I eller et dedikert uptime-verktøy.

Hvorfor flagges http://example.com som en advarsel?

Fordi en URL i klartekst i 2026 nesten alltid er en feil — moderne nettlesere advarer brukere før skjemaer sendes over http://, Googles "why HTTPS matters" dekker den lange versjonen, og HSTS-preloadede domener nekter rett og slett å laste over HTTP. Advarselen er rådgivende; om du virkelig mener http:// (legacy-intranett, lokal dev), ignorer den.

Hva med relative URL-er som /api/orders?

URL-konstruktøren trenger en absolutt URL — uten en base kan den ikke avgjøre protokoll eller vert. Validatoren returnerer i det tilfellet isValid: false med en klar feilmelding. For å validere en relativ URL, sett først en base som https://example.com foran.

Er påloggingsdetaljer i URL-er alltid feil?

Nesten alltid. RFC 3986 §3.2.1 noterer at påloggingsdetaljer i URL-er er utdatert av sikkerhetsårsaker. De havner i nettleserhistorikk, i serverens access-logger og i proxy-cacher. Moderne nettlesere fjerner dem stille fra utklippstavle-innliminger. Validatoren flagger dem så du har et eksplisitt spor før de lekker et sted de ikke burde.

Bryr den seg om IDN-domener?

Ja — validatoren noterer om vertsnavnet er i Punycode-form (xn--...) eller ren ASCII. Nettlesere kan vise Unicode-formen til brukere mens de sender Punycode-formen over linjen, og det er kilden til IDN-homografangrep. Å løfte frem Punycoden er et lite, men nyttig signal.

Andre URL- og JSON-verktøy

Validering er én operasjon. Her er det som passer naturlig sammen med den: