Klistra in din trasiga URL här och klicka på "Fixa URL!!" för att reparera denAnge trasig URL

Vad är URL-fixaren?

Du har kopierat en länk från ett mejl, ett Word-dokument, ett Slack-meddelande eller en Confluence-sida — och nu står den med böjda citattecken runt om (" i stället för "), ett tankstreck (–) där det ska vara ett bindestreck, inget https:// i början, eller en vilsen radbrytning som klippt URL:en i två. Klistra in den här och få tillbaka en fungerande URL. URL-fixaren städar upp den syntaktiska skadan som copy-paste lämnar efter sig, enligt reglerna i WHATWG URL Standard och RFC 3986.

Fixaren tar hand om sådant en regex skulle behöva specialfallshantera i evighet: typografiska citattecken, typografiska tankstreck, oavsiktliga dubbla snedstreck i sökvägen, blandad eller dubbel percent-kodning (alltså %2520 blir %20 när det uppenbart är dubbelkodning), okodade mellanslag, och CR/LF/tab-tecken som hamnat inuti URL:en när någon tryckte Retur vid fel tillfälle. Den hittar inte på något värdnamn, ändrar inte dina query-parametrar och lägger inte till ett sökvägssegment som inte fanns där. Utdatat valideras sedan mot reglerna i webbläsarens URL-API, så att du vet att den faktiskt går att parsa på andra sidan. Internationaliserade värdnamn (Unicode, IDN) bevaras enligt RFC 3987.

Din URL åker till backend så att fixet kan köras, och kommer rakt tillbaka. Vi loggar inte indatat — URL:er bär ofta sessions-tokens, kund-ID:n eller annat du inte vill ha sittande i en loggfil. Om din URL innehåller en riktig hemlighet (en signerad S3-länk, en engångs-auth-token), rotera den efter att du klistrat in den någonstans — även här.

Så använder du URL-fixaren

Tre steg. Vart och ett motsvarar en knapp på den här sidan — inget gömt.

Klistra in den trasiga URL:en eller ladda exemplet

Släpp in din trasiga URL i editorn till vänster. Klicka på Exempel-URL för att ladda ett medvetet trasigt exempel med böjda citattecken, ett tankstreck, saknat schema och ett okodat mellanslag — precis det du faktiskt klistrar in från ett mejl. Exempel på en trasig URL:

"shop.example.com/orders/ORD–1001?customer=Ava Chen"

Böjda citattecken från ett Word-dokument runt URL:en, tankstreck inuti sökvägssegmentet, inget schema och ett bokstavligt mellanslag i query-värdet. Fyra olika problem på en enda kort rad.

Klicka på Fixa URL!!

Tryck på den gröna knappen Fixa URL!!. Fixaren tar bort citattecknen runtomkring, byter ut tankstrecket mot ett bindestreck, lägger på https:// i början och percent-kodar mellanslaget så att resultatet följer RFC 3986.

Kopiera den fixade URL:en

Höger panel visar den uppstädade URL:en. Skumma igenom den, kopiera, klistra in i webbläsaren, ditt fetch()-anrop, ditt README eller testet som föll. Vill du se URL:en uppdelad i sina delar, skicka den vidare genom vår URL-parser.

När du faktiskt använder det här

Länkar inklistrade från mejl eller Word

Outlook och Word förvandlar tysta raka citattecken till böjda och bindestreck till tankstreck. URL:en ser fin ut i meddelandet och går sönder i samma sekund som du klistrar in den i en terminal. Fixaren backar den "smarta" autokorrigeringen så att länken funkar igen.

URL:er omslutna av citattecken från en logger

JSON-formaterade applikationsloggar älskar att skriva ut URL:er som "https://api.example.com/v1/orders?id=ORD-1001". När du grabbar tag i den för en snabb curl följer de omslutande citattecknen med. Fixaren tar bort dem och du slutar undra varför ditt skal klagar på ett oavslutat citattecken.

Radbrytningar mitt i URL:en från Slack eller Jira

Långa URL:er i Slack, Jira eller en Confluence-sida bryts ofta och plockar upp ett vilset \n när du kopierar dem. Sökvägen ser rätt ut, men fetch() avvisar URL:en med ett parsefel. Fixaren plattar ut radbrytningarna så att URL:en är en sammanhängande sträng igen.

Dubbelkodade query-strängar

När en URL passerar två system som båda percent-kodar hamnar du med %2520 där det skulle stå %20. Fixaren komprimerar de uppenbara dubbelkodningarna tillbaka till ett enda lager — användbart när du felsöker omdirigeringskedjor eller webhook-payloads.

Vanliga frågor

Sparas min URL eller skickas den någonstans jag inte ser?

Din URL åker till vår backend så att fixet kan köras, och kommer rakt tillbaka. Vi loggar inte själva indatat — URL:er bär ofta sessions-tokens eller PII i sökväg/query. Vi loggar att en fix ägde rum, inte vad som fixades. Om URL:en innehåller en riktig hemlighet (en signerad länk, en auth-token), behandla den som exponerad så fort du klistrar in den i något tredjepartsverktyg — även det här — och rotera den.

Vilka URL-fel fixar det egentligen?

De vardagliga: saknat schema (default https://), böjda/typografiska citattecken runt URL:en, tankstreck eller långt streck där det ska vara bindestreck, oavsiktliga // i sökvägen, dubbel percent-kodning (%2520 → %20 när det uppenbart är dubbelkodat), okodade mellanslag i query-värden, tab/CR/LF-tecken som en ordbehandlare släppt inuti URL:en, och omslutande vinkelparenteser som <https://example.com> från Markdown-länkar.

Ändrar den mina sökvägs-, query- eller fragmentvärden?

Nej. Fixaren är medvetet konservativ. Den hittar inte på en host, gissar inte ett saknat TLD, lägger inte till eller tar bort sökvägssegment, lägger inte till eller tar bort query-parametrar, ändrar inte parameterordningen och kastar inte fragmentet. Den rör bara tecken som är syntaktiskt fel. Går customer=Ava Chen in kommer customer=Ava%20Chen ut — samma värde, bara korrekt kodat enligt RFC 3986.

Stöder den internationella (Unicode-)domännamn?

Ja. Unicode-tecken i värd eller sökväg bevaras som Internationalized Resource Identifiers (IRI-formen). Om din applikation behöver punycode-formen (ASCII) för värden, kör den uppstädade URL:en genom ditt språks URL-bibliotek — Nodes url-modul, Pythons idna-paket eller webbläsarens inbyggda URL-konstruktor ger dig båda formerna.

Hur är det med riktigt långa URL:er?

Det finns ett tak på 64 KB för indatat — ungefär 64 000 tecken. Riktiga URL:er ligger nästan alltid under 2 000 tecken; om din är större beror det oftast på att något har dubbelkodats till en stor klump, eller att en binär payload sitter i query-strängen som egentligen ska vara i en POST-body. Fixaren talar om att indatat är för stort; korta ner eller strukturera om först.

Den returnerade ett fel istället för en fixad URL. Vad gör jag nu?

Vissa indata är för långt borta — till exempel en URL där värden helt saknas, eller en där strukturen är så förvanskad att modellen inte kan avgöra vad som var meningen. Då: kolla på URL:en, fixa det uppenbara för hand (host och schema är de vanliga skyldiga) och kör om. Du kan också släppa resultatet i vår URL-validator för att se exakt vad URL-parsern klagar på.

Andra URL-verktyg du kan behöva

Att fixa URL:en är ett steg. När den parsas rent tar de här verktygen den hela vägen: