In 2024 I forked Postlight Parser to use in Capy Reader and returned the name to Mercury Parser. I really, really wanted to use the upstream version of the parser to avoid maintaining something off to the side. But nearly two years on, I feel I made the right choice for the scope of the app.
\nThat’s why I’m happy to announce Mercury Parser version 3.0. My fork of this project follows romantic versioning, or romver meaning that version 3 represents a major overhaul to how the project is developed.
\nFor starters, the app no longer uses jQuery. The previous version of the app used jQuery for the web-based version of the parser. This was completely removed by upgrading Cheerio to the latest version. Cheerio is responsible for much of the parsing in Mercury Parser and follows a similar interface to jQuery, just without the jQuery.
\nNext, I replaced moment.js with dayjs for article date handling. This was another necessary shift since moment.js had been deprecated for several years. The shift was mostly one-to-one but there were a few trade-offs. Date patterns like DD are now replaced by D which was something lenient in moment.js. Date boundaries and timezone suffixes were also changed. This required manual code in the date-published cleaner.
I also migrated from Karma for web tests to Vitest with Playwright. For now this means that the fixtures are only tested in node due to the constraint of the node-only fs import. This is something I may revisit in future for broader test coverage. Lastly, I migrated the project from yarn v1 to npm. There’s safety in defaults, and npm has come along way with performance since Mercury Parser launched in 2016.
All in all, these changes have been easy to manage because my fork of Mercury Parser is a hobby project. There’s no stakeholders, no mission critical applications. That, and Claude Code Opus 4.5 is just leagues better than me at catching package conflicts. It’s been a fun journey to continue to revitalize this project in my spare time and use it in Capy Reader.
\nIf you use this fork and have feedback, let me know! If you use the full content extractor in Capy Reader and enjoy its benefits, consider sponsoring my efforts on GitHub or Ko-fi.
\n", "date_published": "2026-01-19T16:48:11-05:00", "url": "https://jocmp.com/2026/01/19/mercury-parser/", "tags": ["programming","mercury parser"] }, { "id": "http://jocmp.micro.blog/2025/07/12/full-content-extractors-comparing-defuddle/", "title": "Full Content Extractors: Comparing Defuddle and Postlight Parser", "content_html": "One of the hardest problems with RSS feeds is displaying full content. It’s essentially an unsolvable problem given the complexity of webpages and the lack of adherence to a semantic layout for any given blog or news site. It would be nice if each page had a header tag, and an article tag, but it’s not that simple. Full content parsers attempt to solve this, but each has their own set of trade-offs.
\nTools like Mozilla’s Readability.js used to solve this in the past, but given their recent woes it’s hard to trust it as a tool. Postlight Parser née Mercury Parser was a better option. Instead of trying to solve all webpages with a set of common heuristics, each domain could be overridden with a custom parser. In effect, The Verge could have a Verge-specific parser while Ars Technica could have a slightly different parser.
\nIt would be simple to stop there, but Postlight Parser was a product of its time. Around 2015, there was a push by Google to speed up the web by simplifying webpages with AMP. Postlight was one of many companies that stepped in with their own set of tools like the parser to improve development with AMP. But as time passed, AMP fell out of fashion, and Postlight was acquired by NTT Data.
\nPostlight Parser essentially ended with the acquisition. It’s still possible to find Postlight Parser in the wild, however. Feedbin, a web-based feed reader, uses Postlight Parser to power its full content mode. Core development has ground to a halt with the last release in 2022.
\nReadability.js and Postlight Parser may very well represent the past of full content extraction. However a new project called Defuddle might take their place. Defuddle was released in early 2025 by the developer behind the note-taking app Obsidian. It takes the Readability.js route of a one-size-fits-all input function with different internal heuristics.
\nThe following is a brief and non-exhaustive comparison between v2.2.3 of Postlight Parser and v0.6.4 of Defuddle using a small node.js application (source code on GitHub). Defuddle seems to work best when the site’s markup is already well formatted which is the case with The Verge. In the following review article, Defuddle picks up more images, headers, and content like the overall review score than Postlight Parser.
\n![\"\"](\"https://cdn.uploads.micro.blog/238475/2025/parser-compare-verge.png\")
\nParsing fails if you throw an article from Yahoo News Singapore at either Defuddle or Postlight Parser. Defuddle has a slight edge in that it at least extracts images and article content but still captures garbage text like “ADVERTISEMENT.”
\n![\"\"](\"https://cdn.uploads.micro.blog/238475/2025/parser-compare-yn-sg.png\")
\nIn short, better base markup still results in a better outcome. Defuddle is clearly the project to watch given Postlight Parser’s lack of updates, and it’s backed by a live project with Obsidian. Full content parsers come and go but the need to tame the chaos of the web is never ending.
\n", "date_published": "2025-07-12T18:03:00-05:00", "url": "https://jocmp.com/2025/07/12/full-content-extractors-comparing-defuddle/", "tags": ["rss","programming","mercury parser"] } ] }