Count opening-tag-like patterns after removing matching HTML comments. Totals describe source matches, not a parsed DOM, valid nesting or the number of visible elements.
The HTML tag counter lists frequencies of opening-tag-like strings in pasted source. Paste the relevant HTML and select Count Tags to populate the table and totals. The tool does not fetch a URL, render a page or inspect the browser's live DOM. Use it for a quick source inventory, such as checking which element names occur in a fragment, while keeping that narrow scope separate from questions about validity, accessibility or actual rendered content.
Choose a complete page or a fragment deliberately. Shared navigation and footer components can account for many matches in a whole-page sample, while an isolated article snippet may contain very few. Keep the scope with the report when comparing revisions. A different total can simply reflect that one copy included the site shell and another did not, rather than a meaningful change in the content region you intended to review.
The function trims the outer input, removes matching HTML comment blocks and searches for a less-than sign followed by optional whitespace and a run of letters, digits or hyphens. It does not require a complete valid element with a closing angle bracket or paired end tag. The result is therefore a count of source patterns. A malformed opening-like string can be included even when a proper HTML parser would interpret it differently.
Closing tags begin with a slash and are not counted by that rule. A doctype marker does not match the same opening pattern either. Attribute text is not parsed into a structured element. If tag-like text appears inside a script string or another context the matcher does not exclude, it can contribute a result. Inspect unexpected names in the source before calling them actual DOM elements or evidence that the page contains the corresponding visible structure.
For “<div><p>A</p><p>B</p></div>”, the matcher finds three openings: one div and two p entries. Total tags is three, while unique tags is two because only two recognized names occur. End tags are not added to those totals. This small example separates element-name frequency from the count of distinct names and explains why a page with many repeated list items can have a high total but a relatively small unique-name count.
The table is sorted by descending frequency. It is not a ranking of semantic importance or a record of where the elements occur. A frequently repeated span may be a design wrapper, while one main or heading element can carry substantial document meaning. Use the frequency view to decide where to inspect the source, not to conclude that the most common tag is the most important content or that a small variety of tags guarantees a simpler usable page.
Matched names are lowercased before aggregation, so ordinary DIV and div spellings combine in the same row. Hyphens can remain in names, which allows a custom element such as my-card to be counted. The rule is not a full namespace-aware parser: a name containing a colon can be cut at the point not included in its character set. That matters when the sample mixes HTML-like markup with XML or other embedded conventions.
A name that looks unusual is worth checking rather than automatically correcting. It might be a legitimate custom element, a malformed source fragment or a string in an example. The counter does not determine which interpretation is correct. For a production inventory that needs document-tree accuracy, use an appropriate parser and compare the generated DOM. Keep this source-level result labeled clearly so it is not mistaken for a formal count of every actual element in all markup languages.
Matching comment blocks are removed before the opening-pattern scan, so a simple commented “<p>example</p>” does not contribute the p opening. That makes the result different from a raw search through every character in the source. The removal is still a text pattern, not a complete grammar for template languages or comment-like strings embedded elsewhere. Source conventions that use those delimiters can therefore affect what remains for counting in ways that need review.
Keep the original when investigating an unexpected difference between versions. A template comment added around a region can lower the reported total without deleting the underlying source text from your file. Conversely, tag-looking text in a script string can still appear as a match if it survives the preprocessing. These cases are reasons to inspect context, not evidence that the page actually gained or lost the same number of visible nodes a visitor would encounter after rendering.
The counter does not verify closing partners, legal nesting or required attributes. A source with balanced-looking totals can still be malformed, and a large number of void elements can be valid without paired end tags. It also does not check heading hierarchy, alternative text, link destinations or whether the content explains its subject. Those are separate structural and editorial questions that cannot be reduced to the frequency of opening names in a table.
For a heading review, use the Heading Structure Checker and understand that it also has pattern-based limits. For general validity, inspect the markup with a suitable validator or parser. A performance review likewise needs more than tag totals: script behavior, styling, actual DOM and resources all matter. Report the source measurement directly rather than implying that fewer matches automatically mean faster, more accessible or better-ranking pages in every application.
Use the same template state and content boundaries when comparing a before-and-after table. Generated timestamps, optional components and copied examples can change the source even when the main article is unchanged. Record which region was supplied and review the names that changed most. A wrapper removal may be intentional, but verify the resulting layout and interactions instead of assuming a reduction in matched div entries proves a successful refactor.
When another tool reports a different number, check whether it parses DOM nodes, counts closing tags or includes comment text. Those methods answer different questions. This counter uses a specific preprocessing and opening-pattern rule, so exact agreement should not be assumed. Retain a small sample that demonstrates the difference and describe which method fits your actual task before treating either total as an error or presenting one as an authoritative count of the whole deployed page.
Select Count Tags again after editing the input because the table represents the last explicit calculation. The table is cleared and rebuilt for the new sample. Clear empties the input and hides the result panel; it does not preserve a historical inventory. Save the checked source and report through your normal notes if a review needs to be reproduced later, and use a known three-opening example to confirm how the totals are defined.
Finish with a context check of any surprising matches. A plain-text input can legitimately produce zero without establishing that a separate page lacks HTML, and an invalid fragment can produce matches without being a usable document. The useful outcome is an honest source inventory with clear definitions. It is not a validity certificate, a complete rendering audit or a search-performance score simply because opening tags have been counted and arranged by frequency.
It counts opening-tag-like source patterns after matching comment blocks are removed. It does not build a DOM.
No. Closing-tag patterns do not match the opening rule used here.
Total is the number of matched openings; unique is the number of different lowercased matched names.
Yes. Names are lowercased before their frequencies are grouped.
Hyphenated names can match. Other naming conventions, including colon-containing namespaces, need careful interpretation.
Simple matching comment blocks are removed first, so their contents are excluded under that preprocessing rule.
Yes. The scan is pattern-based and does not exclude every raw-text or scripting context.
No. The pattern does not validate a full opening tag, closing partner or legal nesting.
No. Performance, validity and usability require separate evidence beyond this count.
No. Select Count Tags again to rebuild it from the current input.