URL

Valideringsrapport

Vad är URL-validatorn?

Du klistrar in en URL och får tillbaka en strukturerad rapport: är den välformad, hur ser varje komponent ut och vad bör du hålla utkik efter. Validatorn kör URL:en genom webbläsarens inbyggda URL-konstruktor — som implementerar WHATWG URL-standarden — och lägger sedan kontroller per komponent ovanpå.

En "giltig URL" är inte bara en som parsas. En URL som http://10.0.0.5/admin?token=abc123 parsas utmärkt, men har tre saker du förmodligen vill få flaggade: http:// istället för https://, en IP-litteral som värd och en token i query-strängen. Validatorn lyfter alla tre som varningar, separat från pass/fail-kontrollen. Den underliggande syntaxen kommer från RFC 3986; värdnamnsöverväganden från RFC 1034 och driftserfarenhet.

Utdata är JSON, så du kan pipa det till ett CI-script eller en debug-logg. Allt körs i din webbläsare — URL:en lämnar aldrig din maskin. Vill du bara dela upp URL:en i komponenter utan valideringslagret, använd URL Parser istället. Internationaliserade domännamn hanteras enligt IDNA-regler.

Så använder du URL-validatorn

Tre steg. Varje steg motsvarar en knapp på den här sidan.

Klistra in en URL eller ladda exemplet

Släpp en URL i vänsterpanelen. Klicka på Exempel för att ladda en ren, välformad URL med procent-kodade query-parametrar:

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

Validatorn uppdateras medan du skriver. Prova gränsfall: http://-URL:er, IP-litterala värdar, URL:er med autentiseringsuppgifter, värdar med en enda etikett (utan TLD), Punycode-domäner. Var och en lyfter en annan varning.

Läs rapporten

Högerpanelen visar en JSON-rapport med tre toppfält: isValid (om URL:en parsade alls), checks (status per komponent — protokoll, hostname, port, pathname) och warnings (rådgivande punkter som inte är syntaxfel men som du förmodligen bryr dig om).

Kopiera eller ladda ner

Klicka på Kopiera för att skicka JSON-rapporten till urklipp, eller Ladda ner för att spara den som .json. Minifiera packar rapporten på en rad om du behöver den för en loggrad.

När du faktiskt skulle använda det här

Granska en config-fil före deploy

Din service-config har 40 URL:er — webhook-endpoints, OAuth-callbacks, integrationer med tredje part. En har ett inbäddat lösenord från ett glömt test, två pekar fortfarande på http://-stagingvärdar. Att klistra in dem en i taget i validatorn fångar alla tre innan de går live. Krav på URL-format dyker också upp i OAuth 2.0-specifikationen för redirect-URI:er.

Granska URL:er användare skickat in i ett formulär

En användare skickar in ett "webbplats"-fält som visar sig vara example — inget protokoll, ingen TLD, bara ett ord. Eller https://192.168.1.5 — ser giltigt ut, parsar giltigt, men du vill nästan säkert inte rendera det som profil-länk. Validatorn lyfter båda: TLD-saknas-varning på den första, IP-litteral-värd-varning på den andra.

Diagnostisera varför en redirect misslyckas

Din OAuth-callback returnerar 400 med "invalid redirect_uri." URL:en ser bra ut i webbläsaren. Du klistrar in den i validatorn och du ser det: sökvägen har ett bokstavligt mellanslag, och din auth-leverantör jämför strängar byte för byte efter kanonisering. Varningen ("path contains unencoded space") var svaret.

Upptäcka en Punycode-vs-Unicode-missmatch

Du förväntade dig att se münchen.example.com i rapporten och såg istället xn--mnchen-3ya.example.com. Det är Punycode-formen — det som skickas över ledningen — och validatorn flaggar den så att du vet att den ursprungliga indatan hade icke-ASCII-tecken. Användbart när användaren i en buggrapport kopierat och klistrat in en URL från en IDN-domän.

Vanliga frågor

Vad betyder "giltig" egentligen här?

Två lager. isValid: true betyder att webbläsarens URL-konstruktor accepterar indatan — alltså att syntaxen är välformad enligt WHATWG URL-standarden. warnings är separat: saker som är syntaktiskt giltiga men förmodligen inte vad du vill (osäkert protokoll, IP-litteral, inbäddade autentiseringsuppgifter, saknad TLD osv.). En URL kan vara giltig och ändå ha varningar.

Kontrollerar det om URL:en faktiskt resolvas till något?

Nej — det skulle kräva en nätverksbegäran, och det här verktyget körs helt i din webbläsare utan utgående anrop. Validatorn kontrollerar bara syntax och ytliga heuristiker. För nåbarhetskontroller, använd curl -I eller ett dedikerat uptime-verktyg.

Varför flaggas http://example.com som varning?

För att en klartext-URL 2026 nästan alltid är ett misstag — moderna webbläsare varnar användare innan formulär skickas över http://, Googles "why HTTPS matters" täcker den långa versionen, och HSTS-preloadade domäner vägrar helt enkelt ladda över HTTP. Varningen är rådgivande; om du verkligen menar http:// (legacy-intranät, lokal dev), ignorera den.

Och relativa URL:er som /api/orders?

URL-konstruktorn behöver en absolut URL — utan en bas kan den inte avgöra protokoll eller värd. Validatorn returnerar isValid: false med ett tydligt fel i det fallet. För att validera en relativ URL, sätt först en bas som https://example.com framför.

Är autentiseringsuppgifter i URL:er alltid fel?

Nästan alltid. RFC 3986 §3.2.1 noterar att autentiseringsuppgifter i URL:er är utfasade av säkerhetsskäl. De hamnar i webbläsarhistorik, i serverns access-loggar och i proxy-cachar. Moderna webbläsare tar tyst bort dem från klipp- och klistringsoperationer. Validatorn flaggar dem så du har en tydlig spår innan de läcker någonstans där de inte borde.

Bryr den sig om IDN-domäner?

Ja — validatorn noterar om hostnamnet är i Punycode-form (xn--...) eller ren ASCII. Webbläsare kan visa Unicode-formen för användare medan Punycode-formen skickas över ledningen, vilket är källan till IDN-homografattacker. Att lyfta Punycoden är en liten men användbar signal.

Andra URL- och JSON-verktyg

Validering är en operation. Här är vad som passar naturligt ihop med det: