Lim inn den ødelagte HTML-en din her og klikk "Fiks HTML!!" for å reparere denSkriv inn ugyldig HTML

Hva er HTML-fikseren?

Har du HTML som er nesten riktig, men ødelegger siden? En ulukket <p>, en forvillet </div>, eller en href uten anførselstegn kan kaste resten av dokumentet i en rar parse-tilstand. Nettleseren gjør sitt beste med dårlig markup — men resultatet er sjelden det du ville ha. Lim det inn her, så får du tilbake noe parseren er fornøyd med, etter reglene i WHATWG HTML Living Standard.

Den retter seg mot hverdagsbommertene: en manglende sluttag, et anførselstegn som ikke er escapet, en attributtverdi uten ", et listeelement som ikke ble lukket, et blokk-element nøstet der det ikke skal være. Den slags som den offisielle W3C-validatoren flagger én feil om gangen. Fikseren leser hele dokumentet i én slengen og gir deg en ren versjon du kan slippe rett tilbake i prosjektet.

Markup-en din sendes til reparasjonstjenesten over HTTPS og lagres ikke. Har du inline-hemmeligheter som API-nøkler hardkodet i <code>&lt;script&gt;</code> eller <code>data-*</code>-attributter, fjern dem før du limer inn.

Slik bruker du HTML-fikseren

Tre steg. Funker på fragmenter, hele dokumenter eller hva slags rart rot du nå fikk tilbake fra en CMS-eksport.

1

Lim inn ødelagt HTML eller last inn eksempel

Slipp HTML-en din i editoren til venstre. Trykk HTML-eksempel for en liten ordrebekreftelsesside med de typiske feilene — en <head> som aldri ble lukket, et listeelement uten </li>, en usitat href. Eksempel på ødelagt HTML:

<p>Your order <strong>SKU-101 ships tomorrow.
<ul>
  <li>1 x Laptop Stand
  <li>2 x USB-C Cable</li>
</ul>

Tre feil her: <strong> lukker aldri, første <li> avsluttes ikke, og det er ingen </p>. Fikseren lukker dem i riktig rekkefølge.

2

Klikk på Fiks HTML!!

Trykk den grønne Fiks HTML!!-knappen. Vi sender markup-en din til reparasjonstjenesten som lukker åpne elementer etter HTML-syntaksreglene, gjenoppretter attributt-anførselstegn og retter nøsting der det åpenbart er feil. Tekstinnhold, klasser, id-er og inline-stiler er urørt.

3

Sjekk det fiksede resultatet

Høyre rute har den reparerte HTML-en. Slipp den inn i en nettleser, inn i vår HTML-validator for en sanity-sjekk, eller tilbake i CMS-en. For en dypere tilgjengelighetsgjennomgang, bruk et dedikert a11y-verktøy — det er en separat sak fra syntaksreparasjon.

Når du faktisk trenger dette

Fiks output fra CMS eller e-postmaler

WYSIWYG-editorer og e-postmalbyggere elsker å sende ut subtilt ødelagt markup — foreldreløse <p>-tagger, manglende alt-attributter, en og annen ulukket <td>. Kjør eksporten gjennom her én gang før du publiserer, så den rendrede siden ikke hopper uventet på tvers av nettlesere.

Redde markup limt inn fra Office-apper

Word og Google Docs limer inn et virrvarr av <span> og proprietære attributter som ofte har ubalanserte tagger eller forvillede &nbsp;. Fikseren rydder opp i strukturen så du kan fortsette å redigere resultatet i stedet for å skrive det om fra bunnen.

Reparer håndskrevne komponenter

Raske og skitne HTML-snutter i en tutorial, en wikiside eller en gammel README — kopier inn, få det ryddet, lim inn der det skal. Nyttig for å låse opp deg selv når du copy-paster eksempler som funket i noens blogginnlegg men ikke i ditt.

Saneér scrapede sider før parsing

Når du scraper HTML for å mate en ekstraktor, kaster ødelagt markup DOM-baserte parsere ut av spill. Kjør sidene gjennom her først for å gi parseren din en stabil struktur å jobbe med. Par den med en ekte validator hvis du trenger streng konformans.

Vanlige spørsmål

Lagres eller deles HTML-en min?

HTML-en du limer inn sendes til backenden vår over HTTPS for å kjøre reparasjonen, og vi beholder den ikke etter at svaret er returnert. Det er ingen tredjepartssporere i request-stien. Når det er sagt: hvis siden inneholder hardkodede API-nøkler, interne URL-er eller analytics-tokens, behandle den som enhver annen offentlig liming — strip de sensitive verdiene først.

Hvilke typer HTML-feil fikser den faktisk?

Ulukkede tagger (<p>, <li>, <td>, <span>), feilmatchede lukkinger, manglende eller ubalanserte attributt-anførselstegn, misformet DOCTYPE, forvillede &/</> i tekstinnhold som burde være entiteter, og åpenbare nøstefeil (blokk-element inni et inline-element). Den finner ikke på manglende innhold og skriver ikke om gyldig markup.

Endrer den klassene, id-ene eller inline-stilene mine?

Nei. Fikseren får eksplisitt beskjed om å bare reparere syntaks — klassenavn, id-er, inline-style-attributter, data-*-attributter og event-handlere som onclick sendes gjennom ordrett. Hvis outputtet noen gang ser ut som om noe av det er endret, er det en bug.

Produserer den HTML5, XHTML eller begge?

Den sikter mot HTML5 — det er hva enhver gjeldende nettleser parser. Selvlukkende tagger på void-elementer som <br /> aksepteres på input, men outputtet bruker standard HTML5-form. Hvis du spesifikt trenger streng XHTML-output (sjeldent i dag), bruk et XHTML-bevisst verktøy i stedet.

Hvorfor ikke bare kjøre HTML-en gjennom W3C-validatoren?

Det bør du, for siste runde — W3C-validatoren er sannhetens kilde for hva som teller som gyldig HTML. Men den viser feil én om gangen og fikser dem ikke. Fikseren er for når du vil ha dokumentet lukket opp i én sleng først; deretter kjører du validatoren for å bekrefte.

Og tilgjengelighet — legger den til manglende alt eller ARIA?

Nei, og det er bevisst. ARIA-roller og alt-tekst er innholdsavgjørelser, ikke syntaksavgjørelser. Å legge til en plassholder-alt="" ville maskere et reelt tilgjengelighetsproblem. Kjør en dedikert a11y-revisjon (axe, WAVE, Lighthouse) for det.

Andre HTML-verktøy du kanskje trenger

Å fikse syntaksen er bare starten. Når den parser, er disse fornuftige neste steg: