AngleSharp: a W3C conformant HTML parser for .NET that feels like a browser

The point is the DOM API, not just the parse tree

AngleSharp is a .NET library for parsing angle bracket based hypertext: HTML, SVG and MathML, with unvalidated XML supported too. The claim that makes it interesting is not that it parses HTML, it is that the parser is built on the official W3C specification and the resulting DOM is the specified one, so behaviour matches evergreen browsers. Standard DOM features such as `querySelector` and `querySelectorAll` work for traversal.

The README names the competitor directly, and the difference it draws is API shape rather than speed. Against HtmlAgilityPack, the argument is that the exposed DOM uses the official W3C specified API, so even `querySelectorAll` is available, and that the parser follows HTML 5.1, which defines error handling and element correction rather than leaving malformed markup to guesswork.

The key features list reads like a positioning statement: portable on .NET Standard 2.0, standards conform, extensible with your own services, LINQ enhanced so you query DOM elements naturally without wrappers, fully functional DOM with the lists, iterators and events you know, form submission so you can log in to sites, and navigation through a `BrowsingContext` which the README describes as like a browser tab you can control from .NET.

CSS is parseable too, which is the point of comparison with libraries that only touch markup.

The demo is eight lines and shows the whole shape

The README's example retrieves a page and selects cells out of it, which is a good demonstration because it covers configuration, loading, querying and LINQ in one go.

var config = Configuration.Default.WithDefaultLoader();
var address = "https://en.wikipedia.org/wiki/List_of_The_Big_Bang_Theory_episodes";
var context = BrowsingContext.New(config);
var document = await context.OpenAsync(address);
var cellSelector = "tr.vevent td:nth-child(3)";
var cells = document.QuerySelectorAll(cellSelector);
var titles = cells.Select(m => m.TextContent);

The README then shows the same thing with explicit types declared, which is worth reading side by side if you are coming from a strongly typed mindset. Same calls, but `IConfiguration`, `IBrowsingContext`, `IDocument`, `IHtmlCollection<IElement>` and `IEnumerable<string>`.

Four things are demonstrated: configuring document loading, asynchronously opening the document in a new context, running a query to get the cells of interest, and using LINQ over the DOM. That last point is the one that changes how the library feels in practice. Every collection supports LINQ, and the library also ships extension methods for element collections that are not part of the official DOM, described as useful abstractions alongside jQuery-like construction.

`BrowsingContext` is doing the work a browser tab would do in a headless environment, which is what turns this from a parser into something usable for crawling and form submission.

Target frameworks and the maintenance picture

AngleSharp ships for `netstandard2.0`, `net8.0` and `net10.0`, and on Windows the build also targets `net462` and `net472`. The README's framing is that this keeps the library broadly consumable while letting newer runtimes use runtime and BCL improvements.

That target list explains a fair amount of the codebase's conservatism. Supporting .NET Framework 4.6.2 rules out a lot of newer language and BCL surface, and any project that maintains that kind of range ends up with more abstraction layers than a single-target library.

Activity is not in question. The default branch is `devel`, not `master` or `main`, and the last push was on 2026-09-19, the same day as release 1.8.2. Only 11 open issues against 5,535 stars is unusually low for a project this size.

The 1.8.2 release notes are worth reading as a quality signal, because they are almost entirely about doing the specified thing more precisely rather than adding features. Attribute selector serialization now writes only the case-sensitivity modifier that was actually specified. Collections like `document.forms["x"]` enumerate the underlying sequence once instead of twice. Traversal in `GetElementsByTagName` and `GetElementsByClassName` no longer double-scans each element's children. Selector specificity is computed once instead of on every read.

There is also a genuine correctness fix in there: `Document.Forms` was allocating a new collection instance on every read, which contradicted its own `[DomSameObject]` contract. That is the sort of thing you only find when you are reading the specification closely, which is the project's whole premise.

The ecosystem is where the actual functionality lives

AngleSharp.Core is the foundation, and the README is candid that most real work happens in the satellite repositories. Seven are listed in a table with their purpose.

AngleSharp.Css provides the full CSS parser, CSSOM and styling services. AngleSharp.Js is JavaScript integration for browsing contexts. AngleSharp.Wasm is WebAssembly-oriented integration work. AngleSharp.Xml covers XML, XHTML and related XML-oriented parsing. AngleSharp.Renderer is rendering focused, AngleSharp.Diffing does DOM and markup diffing, and AngleSharp.XPath adds XPath on top of the AngleSharp DOM.

So the claim in the description that the library parses CSS should be read carefully. The parser is there, but computed styling, the CSSOM and rendering are separate packages. Anyone planning an AngleSharp-based tool should decide early whether they need AngleSharp.Css, because a lot of what people want from HTML processing is really CSS processing.

AngleSharp.Diffing and AngleSharp.XPath are the two most obviously useful for testing workflows, where comparing rendered structures or reaching nodes the CSS selector API does not cover are the recurring needs.

Where the specification still has holes

The vision section is unusually honest about the limits. The aim is a solid W3C DOM implementation for HTML, SVG, MathML and CSS brought to the CLR in C#, so that you can do in C# what you do in JavaScript against the DOM, and more.

Then the admission: most parts of the DOM are included, even though some may still miss their fully specified or correct implementation. The stated goal for 1.0 is all practically relevant parts implemented according to the official W3C specification, with useful extensions by the WHATWG.

The API is close to DOM4, with naming adjusted to .NET conventions. That adjustment is worth internalising before reading any code: the shapes are familiar but the spelling is not always identical, and a snippet found elsewhere on the web may not compile.

Migration is handled through a documented path rather than left to guesswork, with a dedicated migration document for moving from 0.9 to 0.10 and later, including 1.0. There is also a frequently asked questions document in the docs folder alongside the tutorials.

The use-case list is a good sanity check on whether this fits your problem: parsing HTML including fragments, parsing CSS, constructing HTML for a view engine, minifying, querying, crawling, gathering statistics, web automation, page analytics, HTML and DOM unit tests, automated JavaScript interaction, and testing script engines.

Performance claims and what they do not cover

The README says performance is quite close to that of browsers, that even very large pages can be processed within milliseconds, and that the library tries to minimize memory allocations and reuses elements internally to avoid unnecessary object creation. The key features list adds that it outperforms similar parsers in most scenarios.

Two things are worth saying plainly about those claims. They are the project's own statements, and there is no benchmark table in the README, so the numbers to hold onto are structural rather than absolute. The release notes are where the real evidence sits, and they are full of work that only matters at scale: not double-scanning children during traversal, computing selector specificity once, building a mutation record only when an observer will consume it, and keeping mutation logic out of HTML tree construction.

That last pattern is the one to notice. Mutation observers are a conditional cost, and making the record conditional is the sort of change that only pays off when you are parsing large documents or driving a live DOM. It also suggests the library is used for real work at volume by someone, which matters more for confidence than any single throughput number.

The one performance-adjacent caveat is behavioural rather than structural: HTML 5.1 element correction means malformed markup gets fixed, and the cost of that correction is real even when the result looks fast.

Editorial conclusion

AngleSharp is the right pick when you need a DOM rather than a tree of custom nodes, because querySelector, LINQ over collections and the form submission machinery come from the specification rather than from a wrapper API, and that difference compounds across a crawler or a test suite. The decision between it and HtmlAgilityPack is closer to a choice about whether you want the standard API or the smaller one. The base library covers parsing and DOM, with CSS in AngleSharp.Css and JavaScript in AngleSharp.Js, so budget for extra packages if you need styling or scripting rather than assuming one package does everything. Start with the simple demo in the README to see the shape of the API, then read the migration document if you are upgrading from 0.9.

Frequently asked questions

Official sources

1. AngleSharp/AngleSharp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases