I found a small model on Hugging Face recently that looked interesting, so I decided to experiment with it. I converted it to ONNX, got it running in the browser with WebGPU, and somehow it turned into one of those little tools I keep using way more than I expected.
It’s called Pulpie, and basically it takes a webpage and pulls out the actual useful content as clean Markdown. I’ve been using it to save DEV posts I want to keep, tutorials I want to read later, and especially documentation pages that don’t have a nice copy-to-Markdown option.
The part I really like is that it doesn’t just dump the whole page into Markdown. The model is only about 210M parameters and is used to classify which parts of the page are actual content and which parts are navigation, sidebars, boilerplate, etc. Then the remaining HTML gets converted normally.
That means things like headings, code blocks, links, tables, and images stay intact.
Today I tried it on a huge Claude Code documentation page with a bunch of tables and code examples, and it handled the whole thing really well. I have also saved long DEV posts to read later with all of the images still included.
I made one version that runs locally in the browser through ONNX Runtime Web and WebGPU. The model is around 800 MB, which sounds chunky for a browser app, but it downloads once, which only took a couple of minutes for me, and then it's stored in browser cache. After that, it loads locally and extraction is almost instant on my machine.
If you want to try it out:
I also made a local FastAPI version if you'd rather run it as a local app instead of using the WebGPU browser version. That one can be downloaded from GitHub:
Pulpie Local UI
A fast web interface for extracting the main content from web pages and HTML into clean Markdown. Powered by the feyninc/pulpie-orange-small 210M EuroBERT encoder model.
Try It Online (No Installation)
You can try the in-browser WebGPU version with no local setup required:
- Live Demo: pulpie.pinkpixel.dev
- WebGPU Space Repository: huggingface.co/spaces/sizzlebop/pulpie-webgpu
Why Pulpie?
Most modern content extractors either use brittle heuristics (regular expressions and readability rules) or heavy generative models (decoders) that generate text token by token.
Pulpie takes a different path:
- Single-pass encoder: Instead of generating text from scratch, it tokenizes the page into blocks and classifies every block as content or boilerplate in a single forward pass.
- Fast and light: The recommended 210M model matches state-of-the-art extractors while running up to 20x faster. On an RTX 4090 GPU, extractions take around 15 to 40 milliseconds.
- Clean Markdown with images: It keeps headlines…
I think this is actually one of my favorite uses for a small specialized model so far. It isn’t generating Markdown or rewriting anything. It just answers a much simpler question:
Is this block part of the page I actually care about?
Once it answers that, regular deterministic tools can handle the rest.
No API calls, no cloud inference, and no giant model needed just to clean up a webpage.
This was just a fun little experiment that ended up working so much better than I expected, but since it's been so useful for me, I thought I'd share it.
I can't be the only one who wants to save everything on the internet!
Top comments (4)
Running the classifier locally is an interesting constraint because it makes the extraction tool more inspectable than a hosted black box. I would keep a small corpus of pages with known boilerplate failures and compare the markdown output on every model or DOM-parser update.
Using the model only as a classifier (content vs. chrome) and leaving the conversion itself deterministic is the right call, and it's the pattern small models actually win at — an LLM rewriting your Markdown loses tables and code fences, a 210M classifier doesn't care.
Curious about the ONNX Web side: an 800 MB download is one thing cached, another on first visit over mobile. Do you quantize (int8) for the browser build, and how bad is the memory ceiling on iOS Safari's WebGPU/WebLLM situation right now? We've been watching WebGPU + transformers.js for in-browser extraction and the story on Safari still feels like "works until it suddenly doesn't" past a certain model size.
Also: how does it behave on SPA docs sites where the content div is hydrated after load? Extraction quality on ReadMe/Stripe-style pages is the test we'd run first.
Yeah, I actually quantized and tried a couple of different versions before settling on the current one. One of the quantized builds lost enough accuracy that extraction wasn’t reliable, and FP16 caused a different problem.
The FP16 ONNX model works fine when shader-f16 is available, but on Linux and some GPU/Chrome combinations that WebGPU feature is disabled. ONNX Runtime would still run without throwing, but the FP16 shaders were producing NaN logits. Since the classifier is basically comparing the two logits for each block, every comparison against NaN evaluated false and the whole page ended up classified as boilerplate.
So right now I’m using the larger FP32 model because the browser compatibility seems to be better, even though the initial download is ~800 MB. It’s cached after the first load, so on desktop that tradeoff has been pretty painless. I haven’t really targeted mobile yet though, and I agree that Safari/WebGPU memory limits are probably where this gets much more interesting.
SPA docs have actually been pretty good in the pages I’ve tried so far, because the app fetches the rendered page content before doing the block classification. ReadMe-style/documentation pages were one of the main things I wanted this for in the first place, and that’s where I’ve probably been happiest with the results. Tables, code fences, headings, links, etc. survive because the model only decides what content to keep; the HTML → Markdown conversion itself stays deterministic.
I’m still testing sites though, so I’m sure somebody will eventually hand it a page that fails.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.