Wat dit hulpmiddel doet
Dit is een HTML-formatter, beautifier en viewer in één pagina. Plak markup van elke omvang — een fragment uit een template, een geminificeerde pagina uit view-source, een e-mailbody, een blok markup dat een editor heeft geproduceerd — druk op Formatteren, en het wordt geparst en weergegeven als een ingesprongen, inklapbare boomstructuur. Tagnamen, attribuutnamen, attribuutwaarden, commentaar en tekst krijgen elk een eigen kleur, elk element laat zien hoeveel kinderen het heeft, en elke tak kan worden ingeklapt zodat een lang document stap voor stap te lezen is.
Er gebeurt hier nog iets tweeds dat een gewone formatter je niet geeft. De boomstructuur wordt opgebouwd door de eigen parser van je browser, wat betekent dat je niet naar je eigen tekst met andere inspringing kijkt — je kijkt naar het document dat je browser daadwerkelijk van die tekst opbouwt. Waar de twee verschillen, zit het interessante deel, en het hoofdstuk hieronder over gerepareerde markup legt uit waarom.
Elk resultaat verschijnt boven het vorige, zodat je twee versies van een fragment kunt vergelijken zonder de eerste kwijt te raken. Resultaten kun je één voor één verwijderen of allemaal tegelijk wissen, en niets overleeft een herlaad van de pagina.
Formatter, beautifier, viewer — en de validatorvraag
Een formatter drukt markup opnieuw af met consistente witruimte: één element per regel, een vaste inspringing per nestingsniveau, een voorspelbare plek voor elk hoekig haakje. Beautifyen is het oudere woord voor dezelfde bewerking, geleend uit de wereld van JavaScript-tooling; een beautifier en een formatter zijn hetzelfde gereedschap onder twee namen. Geen van beide verandert wat de markup betekent, alleen waar de regeleindes vallen — met één voorbehoud over witruimte dat verderop zijn eigen hoofdstuk krijgt.
Een viewer gaat verder. In plaats van tekst af te drukken, geeft hij het geparste document weer als een structuur waarmee je kunt werken: een tabel dichtklappen, de kinderen van een container tellen, één tak van een diep geneste layout volgen zonder sluittags met het oog te tellen.
Een validator is het woord dat niet helemaal bij HTML past, en het is de moeite waard om daar precies over te zijn in plaats van iets anders te beweren. HTML kent geen parsefouten in de zin die XML of JSON die kennen: de specificatie verplicht een browser om te accepteren wat hem ook wordt gegeven, en er hoe dan ook een document van te bouwen. Er is hier dus niets waarop iets kan mislukken, en elke tool die beweert dat jouw HTML "geldig" is, controleert in werkelijkheid conformiteit aan de specificatie — onbekende attributen, elementen op plekken die het inhoudsmodel verbiedt, een ontbrekend verplicht attribuut — en dat is een ander klusje, uitgevoerd door een conformiteitscontrole zoals de W3C-validator.
Wat deze pagina je in plaats daarvan geeft, is aantoonbaar nuttiger in de dagelijkse praktijk: hij toont het document dat je browser heeft gebouwd. Als een tag in de verkeerde volgorde is gesloten of open is blijven staan, zie je waar de browser besloten heeft dat hij hoorde, en dat is precies het gedrag dat je CSS en je JavaScript ook daadwerkelijk tegenkomen.
Je markup verlaat nooit je browser
Niets van wat je hier plakt wordt een netwerkverzoek. De tekst die je plakt, wordt door je eigen browser geparst, weergegeven op de pagina en alleen in het geheugen bewaard — er wordt niets naar een server gestuurd, in een cookie geschreven of in local storage opgeslagen. Verversen wist elk resultaat, en het sluiten van het tabblad ruimt de data op.
Markup lijkt minder gevoelig dan een JSON-payload, tot je kijkt naar wat er doorgaans in zit. Een pagina die uit een ingelogde sessie is gekopieerd, bevat verborgen formuliervelden, CSRF-tokens, sessie-identifiers in URL's, een klantnaam in een kop, een bestelgeschiedenis in een tabel, soms een complete factuur. Een e-mailbody die je plakt om uit te zoeken waarom hij er raar uitziet, is iemands correspondentie. Een formatter die dat allemaal uploadt, heeft van een vraag over vijf seconden layout een gegevensoverdracht gemaakt.
Omdat het parsen in je browser gebeurt, speelt dat allemaal niet. Open je netwerktabblad terwijl je de pagina gebruikt: afgezien van het analytics-baken dat de site bij elke paginalading verstuurt — een URL en een paginatitel — levert formatteren helemaal geen verzoek op. Koppel de netwerkverbinding volledig los en het hulpmiddel blijft werken, en dat is de enige demonstratie van de belofte waarvoor je niemand op zijn woord hoeft te geloven.
Eén gevolg is het vermelden waard: markup parsen betekent dat de browser verwijzingen erin kan oplossen. Deze pagina geeft het document weer als een inerte boomstructuur van tekst in plaats van het als pagina te tonen, dus scripts worden niet uitgevoerd — maar als je markup plakt met een img-tag erin, behandel de bron dan als onbetrouwbaar, zoals je overal zou doen.
Wat de browser doet met kapotte markup
De HTML-parser is verplicht om, wat hem ook wordt gegeven, een document te produceren, en de regels die hij daarbij volgt zijn verrassend eigenzinnig. Ze toegepast zien op je eigen markup verklaart een heleboel bugs die eruitzien als CSS-problemen.
Enkele veelvoorkomende reparaties: een tr die direct in een table wordt geplakt, krijgt er een impliciete tbody omheen, en dat is waarom een stylesheet-selector geschreven als table > tr niets matcht. Een p-element wordt automatisch gesloten zodra er een blokelement in opent, dus een div die binnen een paragraaf staat, eindigt als zijn sibling in plaats van als zijn kind. Inhoud die vóór het eerste element verschijnt, wordt naar de body verplaatst, en een fragment zonder enig html-element krijgt er alsnog een, samen met een head. Overlappende tags worden ontrafeld en opnieuw genest. Een niet-gesloten element slokt alles op wat erna komt, tot iets het gedwongen sluit.
Niets daarvan is een fout, en geen enkele tool waarschuwt je ervoor — het document is gewoon anders dan het document dat je dacht te hebben geschreven. De boomstructuur hier toont het resultaat, zodat een paragraaf die mysterieus zijn opmaak kwijtraakte, een tabelrij die een selector negeert, of een container wiens kinderen één niveau te hoog terechtkwamen, allemaal binnen een paar seconden zichtbaar worden in plaats van na een uur met de inspector.
Beautifyen, minificeren en het voorbehoud over witruimte
Geminificeerde HTML bestaat om dezelfde reden als geminificeerde JSON: witruimte tussen tags kost bytes op de lijn, en een buildstap verwijdert die. Wat overblijft is één regel waarin de structuur volledig door leestekens wordt gedragen — precies de informatie die een lezer nodig heeft, en het enige dat één lange regel niet laat zien. Beautifyen brengt dat weer in vorm — nesting wordt diepte op de pagina, en de omtrek van het document is leesbaar voordat er ook maar iets van de inhoud is gelezen.
HTML heeft een voorbehoud dat JSON niet heeft, en het is de moeite waard daar eerlijk over te zijn. In HTML wordt witruimte tussen inline elementen weergegeven. De spatie in <a>een</a> <a>twee</a> is een echte spatie op het scherm, en die twee links op afzonderlijke ingesprongen regels zetten behoudt hem, terwijl ze samenvoegen hem verwijdert. Dat is waarom een beautifier in specifieke gevallen kan veranderen hoe een pagina eruitziet — inline-block-layouts en white-space: pre-blokken zijn meestal de slachtoffers.
De praktische regel: beautify om te lezen en te debuggen, waar deze pagina voor is, en laat je buildpipeline beslissen over de witruimte van wat je daadwerkelijk uitlevert. Als je de beautified uitvoer terugkopieert naar een template, controleer dan elke inline reeks en elk voorgeformatteerd blok voordat je aanneemt dat de twee gelijk zijn.
Een uitgewerkt voorbeeld
Neem een geminificeerde bestelkaart: een section met een data-attribuut, een kop, een paragraaf met een regeleinde, een tabel met twee rijen zonder tbody, een commentaarregel en een afbeelding. Het is één regel van ongeveer driehonderdvijftig tekens, en er is niets van de structuur te zien.
Geformatteerd telt de kop de elementen, meldt de section zijn kinderen, en toont de tabel een tbody die nooit is getypt — de browser heeft hem ingevoegd, en die ene regel verklaart waarom een selector die rechtstreeks op de tabel is geschreven, zou falen. De br en de img verschijnen zonder sluittag omdat het void-elementen zijn, de commentaarregel staat grijs, en de tabel dichtklappen laat de kaartstructuur in vier regels achter. Klik op "Voorbeeld laden" om precies dat document weergegeven te zien.
Nee. Niets van wat je plakt wordt verstuurd: parsen en weergeven gebeuren in je browser, en het resultaat bestaat alleen op de pagina die voor je staat. Er is geen cookie, geen local storage en geen logging van wat je plakt, en dat is meteen ook waarom een herlaad de resultaten leegmaakt.
Omdat de HTML-parser ze invoegt. Voor een kaal fragment worden een html-, head- en body-element toegevoegd, en er wordt een tbody aangemaakt rond tabelrijen die er geen hebben. Je ziet het document dat je browser bouwt, niet je eigen tekst met andere inspringing, en dat is meestal het nuttigste van de twee.
Niet in de zin van conformiteit. HTML parsen kan niet mislukken, dus er is hier niets om als syntaxisfout te melden; je krijgt de boomstructuur die de browser heeft geproduceerd, waarin verkeerde nesting zich toont als een element op de verkeerde plek. Gebruik voor een conformiteitsrapport tegen de specificatie — verouderde attributen, ontbrekende alt-tekst, schendingen van het inhoudsmodel — een specifieke conformiteitscontrole.
Ja, het zijn twee namen voor het opnieuw afdrukken van markup met inspringing en regeleindes zodat iemand het kan lezen. Deze pagina voegt daar de viewer aan toe: een inklapbare boomstructuur in plaats van een blok tekst, plus een knop Kopiëren die de beautified markup teruggeeft met een inspringing van twee spaties.
Dat kan, op één specifieke manier: witruimte tussen inline elementen wordt in HTML weergegeven, dus regeleindes ertussen toevoegen of verwijderen voegt een spatie toe of verwijdert er een. De blokstructuur blijft ongemoeid. Beautify om te lezen en te debuggen; laat de witruimte van productiemarkup over aan je buildstap.
Nee. De markup wordt geparst tot een inert document en daarna weergegeven als een boomstructuur van tekst, dus er wordt geen script uitgevoerd en geen stylesheet toegepast. Behandel geplakte markup uit een onbetrouwbare bron met dezelfde voorzichtigheid als altijd, maar niets op deze pagina voert het uit.
Op een normale machine ruim een paar megabyte. Het plafond wordt bepaald door het geheugen van je browser en de tijd die het kost om de boomstructuur op te bouwen, niet door een serverquotum, want er is geen server bij betrokken. Grote pagina's lezen prettiger ingeklapt: gebruik "Alles inklappen" en open daarna de tak die je interesseert.
Zodra de pagina is geladen, ja. Parsen en formatteren gebruiken de eigen engine van je browser, dus je kunt de verbinding verbreken en gewoon doorwerken — en dat is meteen ook het simpelste bewijs dat er niets wordt geüpload.