alt Hacker NewsYou are not required to close your <p>, <li>, <img>, or <br> tags in HTML
Comments
Serious question: why would you ever want to not close tags? It saves a couple of key strokes, but we have snippets in our editors, so the amount of typing is the same. Closed tags allow editors like Vim or automated tools to handle the source code easier; e.g. I can type `dit` in Vim to delete the contents of a tag, something that's only possible because the tag's content is clearly delimited. It makes parsing HTML easier because there are fewer syntax rules.
I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have. HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML. Even though I don't have to, I strive to adhere to the stricter rules of closing all tags, closing self-closing tags and only using lower-case tag names.
Go back a bit further for why.
Netscape Navigator did, in fact, reject invalid HTML. Then along came Internet Explorer and chose “render invalid HTML dwim” as a strategy. People, my young naive self included, moaned about NN being too strict. NN eventually switched to the tag soup approach. XHTML 1.0 arrived in 2000, attempting to reform HTML by recasting it as an XML application. The idea was to impose XML’s strict parsing rules: well-formed documents only, close all your tags, lowercase element names, quote all attributes, and if the document is malformed, the parser must stop and display an error rather than guess. XHTML was abandoned in 2009. When HTML5 was being drafted in 2004-onwards, the WHATWG actually had to formally specify how browsers should handle malformed markup, essentially codifying IE’s error-recovery heuristics as the standard.
You are also not required to indent code (in most languages); please do if you want me to read it though.
The “loose” standards of HTML led to some really awful things happening in the early web. I remember seeing, e.g.,
<large><li></large> item text
Really, in 2025 people should just write XHTML and better yet, shouldn’t be generating HTML by hand at all except for borderline cases not handled by their tools.
<p>some sentence here <img src="img.jpeg"/> <p> some other sentence.
In that example, the image could be part of the first paragraph, as it is there, or if i moved the second <p> before the <img> it would be part of the second. but if I want neither, do I not have to close the first paragraph?
Here is a demo of what i mean on this random html paste site: https://htmlbin.online/closetagdemo
I don't know what "not required" means, but it makes a difference with <p> at least in my opinion. I think the author meant that if the succeeding element is of the same type, you don't need to close the previous one.
But even then, this is not a good feature, browsers aren't the only things processing html content, any number of tooling, or even human readers can get confused.
Early Google did not close their tags, I think it was for the sake of payload size?
That said, your linter is going to drive you crazy if you don't close tags, no?
To see the actual errors, just paste your HTML here and see: https://emilstenstrom.github.io/justhtml/playground/ - any parsing errors show up below the input box.
Some tags do require ending tags, others do not. Personally I find it hard to remember which ones, so I just close things out of caution. That way you’re always spec-correct.
I didn’t have any rigorous training or anything, but my understanding since learning HTML way back in high school was, like the author mentions in TFA, tags like <br> and <p> can simply be used “as-is” as markup and don’t need the concept of being closed.
I write virtually zero HTML anymore, but the one time this sort of thing comes up is in writing PR descriptions in GitHub using Markdown. Sometimes I want to add a <br> or two for space. I guess I’ve never stopped to notice that I never close those tags after adding them, or wondered why in my head it makes sense not to!
Yea but it feels gross when I don't.
I use this daily with local HTML files, specifically not closing <li> tags
For example, I generate numbered lists of URLs something like
<li><a href=http://example.com>http://example.com</a>
If I am viewing in graphical browser I wrap the lists in <pre> tags
I don't think I've ever closed <br> tags
Just because you can, doesn't mean you should.
<p> was the only thing I knew when I constructed Finland's First Ever WEB-page in 1992.
Correction: there was also the issue of Ä and Ö. Those were &AUML; and &OUML; I think.
You’re not really required to with anything in HTML or to even use HTML, you could do everything plain text if you wanted
Yeah but it's better for your mental sanity. It's not just a habit, the closure reduces the mental load and helps to keep track of structure in the messy world of html documents. So it is actually more efficient
I cannot fathom writing <p> without</p> to wrap a text.
Please just close them though.
How does all this interact with html minification? IIRC you can't nest p tags but you can nest li, so does browser just make assumptions about your intent. Is it not better to state your intent as clearly as possible if not for a browser, then for the next developer?
Payload size is a moot point given gzip.
I tried using XHTML when we were told, loudly and repeatedly, that it was the inevitable future. Thank god it wasn’t.
You should close your tags. It’s good hygiene. It helps IDEs help you. But. Trust me, you do not want the browser enforcing it at runtime, lest your idea of fun is end users getting helpful error messages like an otherwise blank screen saying “Invalid syntax”.
For fun, imagine that various browsers are not 100.00% compatible (“Inconceivable!”), so that it wasn’t possible to write HTML that every browser agreed was completely valid. Now it’s guaranteed that some of your users will get the error page, even when you’re sure your page is valid.
Conceptually, XHTML and its analogs are better. In practice, they’re much, much worse.
You don't need to close these tags. But if you value your sanity more than saving a few bytes, you as well may close them, it's not an error.
My experience with parsing html gathered from the wild is you're pretty much not required to do anything. "Go wild" and "have fun" seem to be the mottoes.
But I want to!
:)
I'd think handling these cases would be nightmare for html parsers.
I never knew that. I don't know why. I've never seen this mentioned in a book, tutorial, or anything.
Considering I can’t scroll down on ios safari, maybe you should…
There are ways for not closing HTML tags to backfire in some scenarios.
Some rules of thumb, perhaps:
— Do not omit if it is a template and another piece of HTML is included in or after this tag. (The key fact, as always, is that we all make errors sometimes—and omitting a closing tag can make an otherwise small markup error turn your tree into an unrecognisable mess.)
— Remember, the goal in the first place is readability and improved SNR. Use it only if you already respect legibility in other ways, especially the lower-hanging fruit like consistent use of indentation.
— Do not omit if takes more than a split-second to get it. (Going off the HTML spec, as an example, you could have <a> and <p> as siblings in one container, and in that case if you don’t close some <p> it may be non-obvious if an <a> is phrasing or flow content.)
The last thing you want is to require the reader of your code to be more of an HTML parser than they already have to be.
For me personally this makes omitting closing tags OK only in simpler hand-coded cases with a lot of repetition, like tables, lists, definition lists (often forgotten), and obviously void elements.
I get why you may not close <img> or <br> since they don't contain anything inside, but <p> and <li> should be closed to indicate the end of the content, otherwise it's shows you are mentally lazy and relying on some magic to do the work and guess what you wanted
I know some (or even the official?) JavaDoc style guidelines require <p> woithout closing counterparts. But to me this feels the same as omitting semicolins in JS -yes, xou can get away with it, but it's bad style in my opinion.
It would be nice though, to close 'm ... Makes it more readable and less prone to mistakes.
Whether you can or can't omit a closing element is one thing, but it seems like a useful thing to be able to quickly determine if some content is inside or outside a tag, so why complicate things?
(This is especially relevant with "void" tags. E.g. if someone wrote "<img> hello </img>" then the "hello" is not contained in the tag. You could use the self closing syntax to make this more obvious)
Maybe you are not required to close, browsers are ridiculously tolerant to html mistakes. But do you think it would be easy to maintain that HTML file and not accidentally include something in that unclosed tag? I often format with indentation in order to work with the file comfortably.
Also it annoys me when people are still closing tags with '/>'.
Same with <svg> but Firefox's XML parser will not greenlight you.
The HTML Specification (spec) states it is possible to omit closing tags for certain elements when writing HTML documents. ~
In fact, most web browsers now automatically insert these closing tags for the user.
This feature has been around for many years now.
However, I have found that many organizations still require that the closing tags be included explicitly.
I am curious how other organizations determine when to use the "the spec allows it" as a reason to not include the closing tags.
What point do developers cross from merely allowing this to being considered a technical debt?
Have you ever utilized the feature of the specification that caused you a problem later?
If I enter the following:-
<p><p></p>
> Browsers do not treat missing optional end tags as errors that need to be recovered from
Just because it worked on the one browser you tested it on, doesn't mean it's always worked that way, or that it will always work that way in the future...
Every browser treats html/etc differently... I've run into css issues before on Chrome for android, because I was writing using Chrome for desktop as a reference.
You'd think they should be the same because they come from the same heritage, but no...
If I remember correctly Google's front page did this in the early days to save a few bytes.
You are if I’m doing your code review.
…but civilized people do close them.
Please do, though :)
I always thought this was funny. Practical but not the usual open/close order.
aaaaa<b>aaaa<i>aaaaa</b>aaaa</i>aaaaa
<table>
<tr><td>aaaaa<td>bbb
<tr><td>ccccccccccc<td>dddddddddd
<tr><td>eeeeeeeeeeeeeeeee
</table>
Also true: You are not required to bathe IRL.
(But it might be better if you make a habit of doing so.)
The author has a point, but I object to this mischaracterization:
> XHTML, being based on XML as opposed to SGML, is notorious for being author-unfriendly due to its strictness
This strictness is a moot point. Most editors will autocomplete the closing tag for you, so it's hardly "unfriendly". Besides, if anything, closing tags are reader-friendly (which includes the author), since they make it clear when an element ends. In languages that don't have this, authors often add a comment like `// end of ...` to clarify this. The article author even acknowledges this in some of their examples ("explicit end tags added for clarity").
But there were other potential benefits of XHTML that never came to pass. A strict markup language would make documents easier to parse, and we wouldn't have ended up with the insanity of parsing modern HTML, which became standardized. This, in turn, would have made it easier to expand the language, and integrate different processors into the pipeline. Technologies like XSLT would have been adopted and improved, and perhaps we would have already had proper HTML modules, instead of the half-baked Web Components we have today. All because browser authors were reluctant to force website authors to fix their broken markup. It was a terrible tradeoff, if you ask me.
So, sure, feel free to not close HTML tags if you prefer not to, and to "educate" everyone that they shouldn't either. Just keep it away from any codebases I maintain, thank you very much.
To be fair, I don't mind not closing empty elements, such as `<img>` or `<br>`. But not closing `<p>` or `<div>` is hostile behavior, for no actual gain.
> "Did you forget to close your p tags or is that on purpose?" > [...] > These are all adapted from real comments;
If that's a comment you get, write better code. It does not matter to me whether closing p-tags is mandatory or optional. If you don't do it, I don't want you working on the same code base as me.
This kind of knowledge makes for fun blog posts, but if people direct these kind of comments to me. You're obviously using your knowledge to just patronize and lecture people.
Needs a (2017) in the title.
This may have been relevant 9 years ago, but today, just pick and auto-formatter like prettierjs and have it close these tags for you.
[dead]
This a very verbose and confuse article. Mixing P/LI and IMG/BR is wrong. I think the situation could be explained with two points:
1. The autoclose syntax does not exist in HTML5, and a trailing slash after a tag is always ignored. It's therefore recommended to avoid this syntax. I.e write <br> instead of <br />. For details and a list of void elements, see https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme...
2. It's not mandatory to close tags when the parser can guess where they end. E.g. a paragraph cannot contain any line-block, so <p>a<div>b</div> is the same as <p>a</p><div>b</div>. It depends on the context, but putting an explicit end tag is usually less error-prone.
Guess what, you're not required to open <html>, <head>, or <body> either. It all follows from SGML tag inference rules, and the rules aren't that difficult to understand. What makes them appear magical is WHATWG's verbose ad-hoc parsing algorithm presentation explicitly listing eg. elements that close their parents originally captured from SGML but having become unmaintained as new elements were added. This already started to happen in the very first revision after Ian Hickson's initial procedural HTML parsing description ([1]).
I'd also wish people would stop calling every element-specific behavior HTML parsers do "liberal and tag-soup"-like. Yes WHATWG HTML does define error recovery rules, and HTML had introduced historic blunders to accomodate inline CSS and inline JS, but almost always what's being complained about are just SGML empty elements (aka HTML void elements) or tag omission (as described above) by folks not doing their homework.
[1]: https://sgmljs.sgml.net/docs/html5.html#tag-omission (see also XML Prague 2017 proceedings pp. 101ff)