URL

Renset

Hva er URL-renseren?

Du delte en lenke med vennene, og bakerst hang ?utm_source=newsletter&utm_campaign=spring_sale_2026&fbclid=IwAR0.... Lim den inn her, så får du den nakne URL-en tilbake pluss en JSON-oppstilling av nøyaktig hva som ble fjernet. Utdataene er JSON, så du kan kopiere det rett inn i en logglinje, en test-fixture eller hvor som helst du vil ha et spor av hva som ble renset bort.

Siden finnes fordi Google Analytics, Facebook, HubSpot, Mailchimp og et dusin andre plattformer henger ting på URL-er som du verken vil dele eller lagre. utm_*-parametere kommer fra Urchin Tracking Module — Google la dem til i 2005, og nå er de overalt. fbclid er Facebooks klikk-ID, gclid er Googles. Ingen av dem påvirker hvilken side som lastes — de forteller bare destinasjonen hvor du kom fra.

Alt kjører i nettleseren din via standard-API-et URLSearchParams — den samme parseren som WHATWG URL Standard definerer. Ingen opplasting, ingen server, ingen logger. URL-rensningen er deterministisk — strip-listen ligger i kildekoden, du kan lese den, og samme inndata gir alltid samme utdata.

Slik bruker du URL-renseren

Tre trinn. Hvert tilsvarer en knapp på siden.

Lim inn en URL eller hent eksempelet

Slipp en URL i venstre panel. Klikk på Eksempel for å laste et realistisk tilfelle med utm_*, fbclid og gclid blandet sammen med ekte query-parametere. Eksempel-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

Alt new URL(...) aksepterer fungerer — query-strenger med +, prosent-encoding, gjentatte nøkler og hash-fragmenter håndteres alle. Stien, hashen og alle ikke-sporende query-parametere bevares nøyaktig.

Les den rensede URL-en og hva som ble fjernet

Høyre panel viser JSON: cleaned er URL-en uten sporing, removed er et objekt som lister hver fjernede parameter (nøkkel og verdi), og removedCount er totalen. Hvis det ikke var noe å rense, er removed et tomt objekt og et note-felt sier ifra. Oppdateres mens du skriver.

Kopier eller last ned

Klikk Kopier for å sende JSON til utklippstavlen, eller Last ned for å lagre den som en .json-fil. Minifiser komprimerer JSON-en til én linje. Bruk Tøm i inndatapanelet for å starte på nytt. Vil du bare ha den rensede URL-strengen, kopier verdien i cleaned-feltet.

Når du faktisk vil bruke det

Rense lenker før du deler

Du har åpnet en fane fra en markedsføringsmail og vil sende lenken til en kollega på Slack. URL-en drar med seg ?utm_source=newsletter&utm_campaign=spring_sale_2026 bakerst — kollegaen trenger ikke å vite hvor du kom fra, og lenken ser stygg ut. Lim inn, kopier cleaned-verdien, send. Spiller godt sammen med vår URL-parser hvis du først vil inspisere komponentene.

Lagre kanoniske URL-er i en database

Du indekserer sider for en bokmerketjeneste eller pris-tracker. To besøk på samme produkt med ulike utm_campaign-verdier er ikke to sider — det er den samme siden. Strip sporerne før du skriver URL-en til databasen, ellers ender du med duplikater. RFC 3986-spesifikasjonen kaller dette URL-normalisering.

Personvern — ikke gi videre referer-en til destinasjonen

Når du klikker på en lenke med fbclid, forteller du destinasjonssiden at Facebook sendte deg, og gir dem en klikk-ID som Facebook kan koble til kontoen din. Facebooks dokumentasjon beskriver fbclid som klikk-identifikator for annonse-attribusjon. Å fjerne den før du besøker (eller før du lagrer lenken) kutter det sporet.

Rydde i support-saker

"Siden krasjet da jeg klikket på denne lenken" — og lenken er 600 tegn lang fordi den drar med seg utm + gclid + hver eneste HubSpot-sporingsparameter HubSpot noen gang har lansert (__hssc, __hstc, _hsenc, hsa_*). Lim inn, kopier den rensede URL-en, og lim inn DEN i bug-rapporten. Nå kan du faktisk lese selve stien.

Vanlige spørsmål

Hva blir egentlig fjernet?

Alt som starter med utm_ (altså utm_source, utm_medium, utm_campaign, utm_term, utm_content, pluss enhver custom utm_* en markedsfører legger til) — pluss en eksplisitt liste med rundt 50 kjente sporingsparametere: fbclid (Facebook), gclid og dclid (Google Ads), mc_eid og mc_cid (Mailchimp), _ga og _gl (Google Analytics cross-domain), igshid (Instagram), yclid (Yandex), __hsfp/__hssc/__hstc/_hsenc og hsa_* (HubSpot), mtm_* og pk_*/piwik_* (Matomo), vero_id, wickedid, _branch_match_id, _openstat og noen til. Ekte query-parametere som faktisk betyr noe for siden (som customer=Ava+Chen) blir urørte.

Endrer den sti eller hash?

Nei. Bare query-strengen blir rørt. Protokoll, host, port, sti og hash-fragment går gjennom uendret. Så https://shop.example.com/orders/ORD-1001?utm_source=x#summary blir til https://shop.example.com/orders/ORD-1001#summary — samme sti, samme hash, ingen query.

Hva om jeg vil beholde utm_source for min egen analytics?

Akkurat nå er strip-listen fast og bygget inn i siden. Trenger du en custom whitelist eller blacklist, fork kildekoden — Set-et med parametere og utm_*-regexen ligger øverst i komponenten. En fremtidig versjon kan kanskje eksponere dette som en valgmulighet, men de fleste som lander her vil ha den brede standarden.

Hvorfor er fbclid så lang?

Det er en ugjennomsiktig, signert identifikator som Facebook bruker for å tilskrive klikket til en bestemt annonse og (vanligvis) en bestemt bruker. Det eksakte formatet er ikke offentlig, men er grundig dokumentert i Wikipedia-artikkelen om fbclid. gclid er motstykket for Google Ads. Begge kan trygt fjernes fra URL-er du deler eller lagrer — ingen av dem trengs for å laste selve siden.

Fungerer den med URL-er uten sporingsparametere?

Ja. JSON-utdataene har removedCount: 0, et tomt removed-objekt og et note-felt som sier at ingenting ble funnet. cleaned-URL-en blir byte-identisk med inndataene dine (utenom det new URL().toString() normaliserer — for eksempel å legge til avsluttende skråstrek på origin om det manglet).

Hva med gjentatte nøkler, som ?utm_source=a&utm_source=b?

Begge fjernes. URLSearchParams.delete(name) sletter alle oppføringer med det navnet, så duplikater er ikke et problem. removed-objektet vil bare vise én verdi (den sist parsede), men i praksis legger ingen inn dobbel utm_source i en ekte URL.

Andre URL-verktøy

Rensing er én operasjon. Det som naturlig hører sammen med det: