Indsæt din ødelagte HTML her og klik på "Fix HTML!!" for at reparere denIndtast ugyldig HTML

Hvad er HTML-fixeren?

Har du HTML der næsten er rigtig, men ødelægger siden? En ulukket <p>, en vildfaren </div> eller en href uden anførselstegn kan kaste resten af dokumentet i en mærkelig parse-tilstand. Browseren gør sit bedste med dårlig markup — men resultatet er sjældent det, du var ude efter. Klistr det ind her, så får du noget tilbage som parseren er glad for, efter reglerne i WHATWG HTML Living Standard.

Den sigter mod hverdagsfejlene: en manglende sluttag, et anførselstegn der ikke er escapet, en attributværdi uden ", et listeelement der ikke blev lukket, et blokelement indlejret hvor det ikke skal være. Den slags som den officielle W3C-validator flagger én fejl ad gangen. Fixeren læser hele dokumentet på én gang og giver dig en ren version, du kan smide direkte tilbage i projektet.

Din markup sendes til reparationstjenesten over HTTPS og bliver ikke gemt. Hvis du har inline-hemmeligheder som API-nøgler indkodet i <code><script></code> eller <code>data-*</code>-attributter, så fjern dem inden du indsætter.

Sådan bruger du HTML-fixeren

Tre trin. Virker på fragmenter, hele dokumenter eller hvad mærkeligt rod du nu fik tilbage fra et CMS-eksport.

Indsæt ødelagt HTML eller hent eksempel

Smid din HTML i editoren til venstre. Klik HTML-eksempel for en lille ordrebekræftelsesside med de typiske fejl — en <head> der aldrig blev lukket, et listeelement uden </li>, en uciteret 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 fejl her: <strong> lukker aldrig, første <li> afsluttes ikke, og der er ingen </p>. Fixeren lukker dem i den rigtige rækkefølge.

Klik på Fix HTML!!

Tryk på den grønne Fix HTML!!-knap. Vi sender din markup til reparationstjenesten, der lukker åbne elementer efter HTML-syntaksreglerne, gendanner attribut-anførselstegn og retter indlejring hvor det tydeligt er forkert. Tekstindhold, klasser, id'er og inline-styles bliver rørt.

Tjek det fixede output

Højre rude har den reparerede HTML. Smid den i en browser, ind i vores HTML-validator for en sanity-check, eller tilbage i dit CMS. For en dybere tilgængelighedsgennemgang brug et dedikeret a11y-værktøj — det er en separat sag fra syntaksreparation.

Hvornår du faktisk får brug for det

Fix output fra CMS eller mailskabeloner

WYSIWYG-editorer og mailskabelonbyggere elsker at sende subtilt ødelagt markup ud — forældreløse <p>-tags, manglende alt-attributter, lejlighedsvis ulukket <td>. Kør eksporten igennem her én gang før du publicerer, så den renderede side ikke hopper uventet på tværs af browsere.

Redde markup indsat fra Office-apps

Word og Google Docs indsætter et virvar af <span> og proprietære attributter, der ofte har ubalancerede tags eller vildfarne  . Fixeren rydder op i strukturen, så du kan fortsætte med at redigere resultatet i stedet for at skrive det om fra bunden.

Reparér håndskrevne komponenter

Hurtige og beskidte HTML-snippets i en tutorial, en wiki-side eller en gammel README — kopiér ind, få det renset, klistr ind hvor det skal. Brugbart til at låse dig selv op, når du copy-paster eksempler der virkede i nogens blogindlæg men ikke i dit.

Saneér scrapede sider før parsing

Når du scraper HTML for at fodre en extractor, vælter ødelagt markup DOM-baserede parsere. Kør siderne igennem her først for at give din parser en stabil struktur at arbejde med. Par den med en rigtig validator hvis du har brug for streng overensstemmelse.

Almindelige spørgsmål

Bliver min HTML gemt eller delt?

HTML'en du indsætter sendes til vores backend over HTTPS for at køre reparationen, og vi gemmer den ikke efter svaret er returneret. Der er ingen tredjepartstrackere i request-vejen. Når det er sagt: hvis siden indeholder hårdkodede API-nøgler, interne URL'er eller analytics-tokens, behandl den som enhver anden offentlig indsætning — fjern de følsomme værdier først.

Hvilke slags HTML-fejl fixer den faktisk?

Ulukkede tags (<p>, <li>, <td>, <span>), fejlmatchede lukninger, manglende eller ubalancerede attribut-anførselstegn, misformet DOCTYPE, vildfarne &/</> i tekstindhold der burde være entiteter, og åbenlyse indlejringsfejl (blokelement inde i et inline-element). Den finder ikke på manglende indhold og omskriver ikke gyldig markup.

Ændrer den mine klasser, id'er eller inline-styles?

Nej. Fixeren får eksplicit besked på kun at reparere syntaks — klassenavne, id'er, inline-style-attributter, data-*-attributter og event-handlers som onclick sendes igennem ordret. Hvis outputtet nogensinde ser ud som om noget af det er ændret, er det en bug.

Producerer den HTML5, XHTML eller begge?

Den sigter mod HTML5 — det er hvad enhver nuværende browser parser. Selvlukkende tags på void-elementer som <br /> accepteres på input, men outputtet bruger standard HTML5-form. Hvis du specifikt har brug for streng XHTML-output (sjældent i dag), brug et XHTML-bevidst værktøj i stedet.

Hvorfor ikke bare køre min HTML gennem W3C-validatoren?

Det bør du, til den sidste tjek — W3C-validatoren er sandhedens kilde for hvad der tæller som gyldig HTML. Men den viser fejl ét ad gangen og fixer dem ikke. Fixeren er til, når du vil have dokumentet lukket op i ét hug først; så kører du validatoren for at bekræfte.

Og tilgængelighed — tilføjer den manglende alt eller ARIA?

Nej, og det er bevidst. ARIA-roller og alt-tekst er indholdsbeslutninger, ikke syntaksbeslutninger. At tilføje en pladsholder-alt="" ville maskere et reelt tilgængelighedsproblem. Kør en dedikeret a11y-revision (axe, WAVE, Lighthouse) til det.

Andre HTML-værktøjer du måske får brug for

At fixe syntaksen er kun starten. Når den parser, er disse fornuftige næste skridt: