URL

Rensad

Vad är URL-rensaren?

Du delade en länk med kompisar och i slutet hängde ?utm_source=newsletter&utm_campaign=spring_sale_2026&fbclid=IwAR0.... Klistra in den här så får du tillbaka den rena URL:en plus en JSON-uppdelning av exakt vad som plockades bort. Utdata är JSON, så du kan kopiera det rakt in i en loggrad, ett test-fixture eller var du nu vill ha en notering om vad som rensades.

Sidan finns för att Google Analytics, Facebook, HubSpot, Mailchimp och ett dussin andra plattformar slänger på saker på URL:er som du inte vill dela eller spara. utm_*-parametrar kommer från Urchin Tracking Module — Google införde dem 2005 och idag finns de överallt. fbclid är Facebooks klick-ID och gclid är Googles. Ingen påverkar vilken sida som laddas — de berättar bara för destinationen var du kom ifrån.

Allt körs i din webbläsare via standard-API:t URLSearchParams — samma parser som WHATWG URL Standard definierar. Ingen uppladdning, ingen server, inga loggar. URL-rensningen är deterministisk — strip-listan ligger i källkoden, du kan läsa den, och samma indata ger alltid samma utdata.

Så använder du URL-rensaren

Tre steg. Varje steg motsvarar en knapp på sidan.

Klistra in en URL eller ladda exemplet

Släpp en URL i den vänstra panelen. Klicka på Exempel för att ladda ett realistiskt fall med utm_*, fbclid och gclid blandade med riktiga query-parametrar. Exempel-URL:

https://shop.example.com/orders/ORD-1001?customer=Ava+Chen&status=active&utm_source=newsletter&utm_medium=email&utm_campaign=spring_sale_2026&fbclid=IwAR0abc123def456&gclid=Cj0KCQjwxyz

Allt som new URL(...) godkänner fungerar — query-strängar med +, percent-encoding, upprepade nycklar och hash-fragment hanteras alla. Sökvägen, hashen och alla icke-spårande query-parametrar bevaras exakt.

Läs den rensade URL:en och vad som togs bort

Den högra panelen visar JSON: cleaned är URL:en utan spårning, removed är ett objekt som listar varje borttagen parameter (nyckel och värde), och removedCount är totalsumman. Om URL:en inte hade något att rensa är removed ett tomt objekt och ett note-fält säger det. Uppdateras medan du skriver.

Kopiera eller ladda ner

Klicka Kopiera för att skicka JSON till urklippet, eller Ladda ner för att spara den som en .json-fil. Minifiera packar JSON-en på en rad. Använd Rensa i indatapanelen för att börja om. Om du bara vill ha den rensade URL-strängen, kopiera värdet av cleaned-fältet.

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

Rensa länkar innan du delar

Du har öppnat en flik från ett marknadsföringsmejl och vill skicka länken till en kollega på Slack. URL:en släpar med ?utm_source=newsletter&utm_campaign=spring_sale_2026 i slutet — kollegan behöver inte veta hur du kom dit, och länken ser ful ut. Klistra in, kopiera värdet av cleaned, skicka. Funkar bra ihop med vår URL-parser om du vill inspektera komponenterna först.

Spara kanoniska URL:er i en databas

Du indexerar sidor för en bokmärkestjänst eller pristrackare. Två besök på samma produkt med olika utm_campaign-värden är inte två sidor — det är samma sida. Plocka bort spårarna innan du skriver URL:en till databasen, annars hamnar du med dubbletter. Specifikationen RFC 3986 kallar det här för URL-normalisering.

Integritet — lämna inte ut din referer till destinationen

När du klickar på en länk med fbclid talar du om för destinationen att Facebook skickat dig och ger dem ett klick-ID som Facebook kan koppla till ditt konto. Facebooks dokumentation beskriver fbclid som klickidentifierare för annonsattribuering. Att ta bort den innan besöket (eller innan du sparar länken) bryter spåret.

Städa supportärenden

"Sidan kraschade när jag klickade på den här länken" — och länken är 600 tecken lång eftersom den drar med sig utm + gclid + varenda HubSpot-spårningsparameter HubSpot någonsin släppt (__hssc, __hstc, _hsenc, hsa_*). Klistra in, kopiera den rena URL:en och klistra in DEN i din buggrapport. Nu går det att läsa själva sökvägen.

Vanliga frågor

Vad tas exakt bort?

Allt som börjar med utm_ (alltså utm_source, utm_medium, utm_campaign, utm_term, utm_content, plus alla custom utm_* som en marknadsförare lägger till) — plus en explicit lista på cirka 50 kända spårningsparametrar: fbclid (Facebook), gclid och dclid (Google Ads), mc_eid och mc_cid (Mailchimp), _ga och _gl (Google Analytics cross-domain), igshid (Instagram), yclid (Yandex), __hsfp/__hssc/__hstc/_hsenc och hsa_* (HubSpot), mtm_* och pk_*/piwik_* (Matomo), vero_id, wickedid, _branch_match_id, _openstat och några till. Riktiga query-parametrar som betyder något för sidan (som customer=Ava+Chen) lämnas orörda.

Påverkar den sökvägen eller hashen?

Nej. Bara query-strängen rörs. Protokoll, host, port, sökväg och hash-fragment går igenom oförändrade. Så https://shop.example.com/orders/ORD-1001?utm_source=x#summary blir https://shop.example.com/orders/ORD-1001#summary — samma sökväg, samma hash, ingen query.

Tänk om jag vill behålla utm_source för min egen analytics?

Just nu är strip-listan fast och inbyggd i sidan. Behöver du en custom whitelist eller blacklist, forka källkoden — Set:et med parametrar och utm_*-regexen ligger högst upp i komponenten. En framtida version kan eventuellt exponera det här som ett alternativ, men de flesta som hamnar här vill ha den heltäckande standarden.

Varför är fbclid så lång?

Det är en ogenomskinlig, signerad identifierare som Facebook använder för att tillskriva klicket en specifik annons och (oftast) en specifik användare. Det exakta formatet är inte offentligt, men det är utförligt dokumenterat på Wikipedias artikel om fbclid. gclid är motsvarigheten för Google Ads. Båda kan tryggt tas bort från URL:er som du delar eller sparar — ingen behövs för att ladda själva sidan.

Funkar det med URL:er utan spårningsparametrar?

Ja. JSON-utdata har removedCount: 0, ett tomt removed-objekt och ett note-fält som säger att inget hittades. Den cleaned URL:en blir byte-identisk med din indata (med undantag för det som new URL().toString() normaliserar — som att lägga till ett avslutande snedstreck på origin om det saknades).

Och med upprepade nycklar, typ ?utm_source=a&utm_source=b?

Båda tas bort. URLSearchParams.delete(name) tar bort varje post med det namnet, så dubbletter är inget problem. removed-objektet visar bara ett värde (det senast parsade), men i praktiken sätter ingen dubbel utm_source i en riktig URL.

Andra URL-verktyg

Rensning är en operation. Vad som passar naturligt ihop med det: