Free Website-to-Markdown Generator — Tested on 11 CMS

The three modes, and the one that was locked

The Markdown Generator offers three ways to convert a page, and it helps to know what each is for. Full mode takes the whole page and turns all of it into Markdown, chrome and all — useful when you want a complete record of everything on the page. Stripped mode throws away the site furniture — the menus, the footer, the pop-ups — and keeps only the real content, which is what most people want when feeding a page to an AI. Custom mode is the powerful one: it shows you sixteen groups of tick-boxes and lets you decide, element by element, exactly what to keep and what to remove.

Custom was the mode that was locked. It displayed a padlock icon, it was greyed out, and it carried the words "Admin only". For every ordinary user it was visibly there but untouchable. That lock had been added during an earlier piece of work without anyone actually asking for it, so the very first job on the generator was simply to give users back the mode they should have had all along.

Why the lock was more tangled than it looked

The obvious assumption is that a locked button is locked in one place — disable the button, job done. It wasn't. The lock was built in three separate layers, stacked on top of one another, and each one on its own was enough to keep a normal user out. The first layer was the button itself: it was marked as disabled and had a grey filter painted over it, so it looked and behaved as dead. The second layer was a piece of page logic that only removed that disabled state if the logged-in user's email address matched one specific administrator address — so even if the button somehow enabled, it only did so for one person. The third layer was on the server: the code that actually does the Custom conversion refused the request outright unless it came from an administrator.

All three had to be removed for the mode to work, and—this is the important part—they had to be removed cleanly. It would have been easy to hack the button on and leave a mess behind: a new secret route, a second way of charging the user, an untested code path. The right outcome was the opposite of that: the Custom button should behave exactly like every other free-tool button on the page, using the same well-worn machinery, so that it charges once, handles usage limits the same way, and carries no special cases at all.

The fix, done by copying what already worked

Every other free tool on the page opens through one shared mechanism — a single function that checks the user, handles the free-usage allowance, and opens the tool. The correct fix for Custom was to route it through that exact same mechanism, rather than invent anything new. So the button was rewired to call that shared opener, the administrator-email check was deleted, the "Custom is currently admin-only" wording was removed, and the administrator restriction was taken off the server endpoint. After that, the Custom button opens the tick panel for anyone, with all sixteen groups of options available, and the charge happens once, in the same place and the same way as every other tool.

An honest account of a wrong turn

This did not go cleanly on the first attempt, and it's worth being candid about why, because it's exactly the kind of mistake this whole report is about. The first attempt over-engineered the fix badly. Instead of reusing the shared opener, it invented brand-new server routes that had no business existing, added a separate free-usage path parallel to the real one, and—worst of all—introduced a bug where a user could be charged twice: once for opening the panel and again for generating. That was the wrong instinct through and through. The correct move was always to copy the pattern that already worked on every neighbouring button, not to build a parallel system. Every invented route was stripped back out, the double-charge path was removed, and the change was reduced to what it should have been from the start: a rewired button, three deletions, and nothing new added.

Key points

• Custom mode was locked to administrators by three separate layers: a disabled/greyed button, an email check in the page logic, and a server-side restriction.
• The lock had been added in earlier work without being requested, so removing it restored the tool's intended behaviour.
• The fix reused the shared free-tool opener every other button uses, rather than inventing a special case.
• A first attempt over-engineered it — new routes, a parallel free path, and a double-charge bug — all of which was removed.
• End state: any user opens Custom with all 16 tick-box groups, charged exactly once, with no new routes anywhere.

How to remove an accidental feature lock cleanly

1. Find every layer of the lock first — the button state, the page logic, and the server check are frequently three separate places.
2. Remove all of them together, since any one left in place will still block the user.
3. Reuse the exact mechanism a working equivalent already uses, rather than building a parallel path.

How to keep a "quick fix" from making a mess

1. Before adding a new route or code path, check whether an existing one already does the job.
2. Confirm no new charging path was introduced — trace where the user is billed and make sure it fires once.
3. Diff your change against the original and delete anything that isn't strictly necessary.

Questions & answers

Why was the mode locked in the first place? An earlier change had made Custom administrator-only, and that restriction was never actually requested. It simply carried over into the version being worked on. Removing the lock didn't add a feature; it restored the tool to the state it was always meant to be in, with Custom available to every user just like Full and Stripped. Treating it as a restoration rather than a new capability is what kept the fix small.

Why not just enable the button and move on? Because enabling the button alone would have fixed nothing. The lock lived in three places, and the other two — the email check in the page logic and the refusal on the server — would still have turned a normal user away. A user would have seen an enabled button that then failed or was rejected, which is worse than an honest padlock. All three layers had to come off together for the mode to genuinely work.

Did any user actually get charged twice? The first, over-engineered attempt introduced that risk by adding a second charging path alongside the real one. It was caught before it mattered and removed entirely. The shipped fix charges exactly once, on the panel's Generate action, through the same billing mechanism every other tool on the page already uses. Opening the panel itself costs nothing.

How do you know nothing else changed on the server? By comparing the list of the generator's routes before and after the fix. The count and the sorted list of its endpoints are identical; the only difference anywhere in the endpoint is the removed administrator guard. That's the proof that the invented routes were fully backed out and the change is as narrow as claimed.

What appeared to be catastrophically wrong

Early in the testing, a result came up that looked like proof the Stripped mode was broken in the worst possible way: a WordPress page that was 118 kilobytes of HTML — a big, content-rich page — came out the other side as just a few hundred bytes of Markdown. On the face of it that is alarming. It reads as though the converter had taken a full page and thrown away all but a scrap of it, which would make Stripped mode useless and untrustworthy.

A result like that demands to be taken seriously rather than explained away. If Stripped really were discarding content, that would be a fundamental fault at the heart of the tool. So the right response was not to assume the tool was fine, but to actually look at what had happened — to read the input and the output side by side and find out where 118 kilobytes had gone.

What was actually happening

The web address being tested was dead. It no longer pointed at a real article; it returned WordPress's standard "this page doesn't exist" error page. And an error page, by its nature, has almost nothing on it — a short heading saying the page is missing, a line suggesting you search or go home, and that's about it. The 118 kilobytes were almost entirely the site's own framework: its scripts, its styles, its navigation and footer, its invisible plumbing. The actual readable content on that error page amounted to a couple of sentences.

So Stripped had done precisely the right thing. It stripped away the framework and the furniture, exactly as designed, and converted the tiny amount of real content that remained. The output was small because the genuine content was small. Nothing had been discarded that should have been kept; there was simply almost nothing there to keep in the first place.

Why this matters for honesty about testing

The whole "Stripped destroys content" conclusion had been built on a single broken test address. That's a general lesson worth stating plainly: a test is only as trustworthy as the input you feed it, and an alarming result from a bad input tells you nothing about the tool. The moment a real, working WordPress page was used instead of the dead one, Stripped captured the entire article correctly — every heading, every paragraph, every list — while still removing the navigation and footer. The tool was never at fault; the test was.

It would have been easy, and wrong, to "fix" a tool that had nothing wrong with it — to start loosening the stripping rules to make the output bigger, which would have re-introduced exactly the chrome leaks the whole effort was trying to eliminate. Diagnosing the real cause first is what stopped a phantom bug from producing a real one.

The one genuine thing the broken test caught

The dead-URL test wasn't entirely wasted, though. Reading its output closely revealed a separate, genuine problem: a Google Tag Manager tracking frame was leaking into the top of the Markdown. That was real, and it got fixed — it's the subject of the next section. So the broken test still earned its keep, just not for the reason first assumed. It exposed a real leak while disproving a phantom one.

Key points

• A page that seemed to prove "Stripped destroys content" was actually a 404 error page served by a dead address.
• The 118KB was almost all framework, scripts and chrome; the real content was two sentences, so the tiny output was correct.
• The conclusion was wrong because the test input was wrong, not because the tool failed.
• On a real, live WordPress page, Stripped captured the full article while removing nav and footer.
• The same broken test still surfaced one genuine fault — a tracking frame leaking into the output.

How to avoid a false alarm like this

1. Before trusting an alarming "content loss" result, confirm the test address actually returns real content and not an error page.
2. Read the actual output — a "this page doesn't exist" heading is the immediate giveaway.
3. Re-run against a page you know is live and content-rich before drawing any conclusion about the tool.

How to separate a phantom bug from a real one

1. Compare the size of the real (non-chrome) content to the output size, not the raw HTML size to the output.
2. Resist "fixing" a tool until you've proven the fault is in the tool and not the input.
3. Still read the output for unrelated issues — a bad test can incidentally reveal a real one.

Questions & answers

So the tool was fine all along? For the content-loss concern, yes, completely. Stripped correctly converted whatever it was handed, and it was handed an almost-empty error page. On real pages it captured the content in full while removing the furniture. The scary byte-count was a property of the input, not a failure of the converter.

How did a dead address end up being tested? The URL used for the test had simply gone stale — the article behind it had been removed or moved, so the site returned its 404 page. It's an ordinary mistake, and precisely why the resolution was to re-test against a confirmed-live page rather than to start changing the tool.

Was anything actually broken? Only the separate tracking-frame leak, which was real and got fixed in the next part. The content-destruction concern was entirely an artefact of the broken test address. One real bug, one phantom — the phantom disproved, the real one fixed.

Why not just make Stripped keep more, to be safe? Because there was nothing to keep — the missing bytes were chrome and framework, exactly what Stripped is meant to remove. Loosening the rules to inflate the output would have re-admitted the menus, footers and trackers the whole effort was removing, turning a non-bug into a real regression.

What was wrong

A Google Tag Manager tracking frame — one of those invisible elements that sites use to load analytics and marketing scripts — was appearing right at the top of the Markdown output, and it was doing so in all three modes. This isn't content by any definition. It's plumbing: a hidden frame whose only job is to let a tag manager run when JavaScript is switched off. Seeing it at the head of a clean content conversion is a bit like finding the wiring diagram stapled to the front of a printed article.

It mattered for two reasons. First, it's noise: anyone feeding the output to an AI or reading it themselves has to mentally skip past a chunk of tracking markup before reaching the actual content. Second, and more importantly, it signalled that the converters weren't removing a whole category of non-content element — and if one tracking frame could get through, so could others.

Why the existing cleanup missed it

The three converters already did some cleanup before converting: they removed scripts and styling, the two most obvious kinds of non-content. But a tracking frame is a different kind of element from a script, and it wasn't on the list. The tag manager, cleverly, hides its frame inside a "no-script" block — a special container whose contents only take effect when JavaScript is unavailable. So there were actually two related things being missed: the frame itself, and the no-script wrapper it sits inside. Neither was in the removal list, so both sailed through into the output.

The fix

The fix was to add both the frames and the no-script blocks to the cleanup step, in all three modes, so they're taken out before the page is ever converted to Markdown. Once that was in place, the Google Tag Manager frame — and any frame like it, from any analytics or embed provider — no longer reaches the output. Removing these is completely safe, because a tracking frame and a no-script fallback are never the page's real content; they exist purely to serve scripts and provide non-JavaScript fallbacks.

Why it's applied to all three modes

It's worth noting the removal was added to Full mode too, not just Stripped. Full mode is meant to keep the page's content in its entirety, but a tracking frame isn't content in either mode's definition — it's invisible plumbing that the user never sees on the live page and would never want in their Markdown. So all three converters strip scripts, styles, no-script blocks and frames as a baseline; the difference between the modes is what they do with the content and chrome after that, not whether they remove tracking plumbing.

Key points

• An invisible Google Tag Manager tracking frame was leaking into the output in all three modes.
• The converters removed scripts and styling but not frames, nor the no-script blocks that hide them.
• The tag manager deliberately hides its frame inside a no-script wrapper, so both had to be removed.
• The fix removes frames and no-script blocks in all three modes, before conversion.
• It's safe: tracking frames and no-script fallbacks are never real content.

How to strip tracking plumbing from a conversion

1. Identify the full set of non-content elements — scripts, styles, tracking frames, and no-script blocks.
2. Remove them at the very start, before any conversion runs.
3. Confirm on a real page that the plumbing is gone but the genuine content remains untouched.

How to catch a whole category, not just one instance

1. When one non-content element leaks, ask what category it belongs to and whether siblings could leak too.
2. Remove by element type (frames, no-script) rather than by one specific provider's markup.
3. Re-test across several sites so a provider-specific fix doesn't masquerade as a general one.

Questions & answers

Why was a tracking frame in the output at all? The cleanup step removed scripts and styles but not frames, and a tracking frame is a distinct element type. Because it wasn't named in the removal list, it passed straight through into the converted output until it was explicitly added.

Could removing frames drop real content? No. Tracking frames and no-script blocks are analytics plumbing and non-JavaScript fallbacks respectively; neither is ever the page's actual content. Removing them only cleans the output and never touches article text, images or lists.

Why remove the no-script block and not just the frame? Because the tag manager hides its frame inside a no-script block. Removing the wrapper removes the frame with it, and adding frames to the list as well catches any frame that isn't wrapped that way. Together they cover every case rather than one.

Why strip it from Full mode too, if Full keeps everything? Full keeps the page's content and chrome, but a tracking frame is neither — it's invisible plumbing the user never sees rendered. All three modes remove scripts, styles, no-script and frames as a shared baseline; they differ only in how they treat the visible content and furniture afterwards.

What was wrong

On a number of sites, the furniture at the top of the page — the site header, the big navigation bar, the drop-down menus that unfold when you hover — was appearing in the Stripped output. Stripped is the mode that's supposed to contain only the real content, so having a site's entire menu structure dumped into it defeats the purpose. Someone converting an article to feed an AI would find the article preceded by a list of every link in the site's navigation.

The reason this happens is that there's a "correct" way to mark up a navigation bar — a dedicated element that says, in effect, "this is navigation" — and Stripped already removed that. But a great many sites don't use it. They build their headers and menus out of ordinary containers with names like "mega-menu", "site-header" or "header-nav", or they mark them only with an accessibility role rather than the semantic element. Those don't announce themselves as navigation in the way the converter was looking for, so they slipped through.

The fix, and the discipline behind it

The wrong way to fix this would have been to pick one site, find whatever its menu happened to be called, and remove that exact name — a patch that fixes one site and no others. Instead, the approach was to look at how these menus are actually built across many real sites and remove them by the patterns that reliably identify navigation regardless of the specific site. That means: a page-level header element; containers whose names contain "site-header", "mega-menu" or "header-nav"; and menus marked with the navigation accessibility role, or with names like "menu-drawer", "mobile-menu" or "dropdown-menu".

There was one deliberate and important restraint here. It would have been tempting to simply remove anything whose name contained the word "menu" — but that would have been a serious mistake. "Menu" is also real content: a restaurant's menu, a menu of services, a tasting menu. A blanket rule keyed on that word would have deleted legitimate content on exactly the kind of site — a restaurant, a café — where that content matters most. So the removal deliberately targets navigation-specific naming and roles, and pointedly does not remove a bare "menu". The furniture goes; the restaurant's menu stays.

Why only Stripped

All of this applies to Stripped mode only. Full mode is designed to keep the whole page, header and menus included, because its job is a complete record. Custom mode lets the user decide, with a tick-box for navigation among the sixteen groups. Only Stripped removes the header and menus automatically, because only Stripped promises content-only output. The same header that's correctly stripped in one mode is correctly kept in another; the behaviour is intentional, not inconsistent.

Key points

• Site headers and navigation menus leaked into Stripped when built without the standard navigation element.
• Removal targets reliable patterns — page-level header elements, "mega-menu"/"header-nav"/"site-header" names, and the navigation accessibility role.
• A bare "menu" is deliberately not removed, so a restaurant or café menu (real content) survives.
• The header removal is scoped to the page-level header, so headers inside articles and sections are kept.
• Applies to Stripped only; Full keeps all furniture, Custom makes it a tick-box.

How to strip navigation without eating content

1. Target the reliable signals: page-level header elements, the navigation accessibility role, and header/mega-menu naming.
2. Avoid over-broad words like a bare "menu" that also appear in genuine content.
3. Test on a site whose real content legitimately uses those words — a restaurant — to prove it survives.

How to keep a fix general, not per-site

1. Inspect several real sites to see how the same furniture is built differently across them.
2. Remove by the shared structural pattern, not by one site's specific class name.
3. Confirm the pattern catches the furniture on sites you didn't use to design it.

Questions & answers

Why not just remove anything called "menu"? Because "menu" is also genuine content — a restaurant's menu, a menu of services. A blanket rule on that word would delete legitimate content on the very sites where it matters most. The removal targets navigation-specific patterns and roles instead, so it strips the furniture while leaving a real menu intact.

How were the right patterns chosen? By inspecting how real sites actually build their headers and menus — the class names and accessibility roles they use — and removing by the ones that reliably mark navigation. That's the opposite of guessing a single class from one site; it's deriving the shared pattern from many.

Does Full mode lose its menus too? No. Full mode intentionally keeps the entire page, chrome included, because it's a complete record. Only Stripped removes navigation automatically, since Stripped's whole promise is content-only output. Custom leaves the choice to the user.

Why scope header removal to the page level? Because an unscoped rule would also strip headers that sit inside articles and sections — which are real content. Restricting removal to the page-level header targets the site banner and masthead only, leaving in-content headers where they belong.

What was wrong

On one site, a phrase came out doubled in the Markdown — something reading like "Smart Gardens Smart Gardens", the same words back to back. Duplicated text is a particularly annoying kind of leak because it makes the output look careless and, if fed to an AI, quietly distorts what the page actually says by repeating things that appear only once to a human reader.

The cause turned out to be a decorative scrolling banner — the kind of ticker or marquee that slides a line of text across the screen in a continuous loop. To make that loop seamless, with no visible gap when the text wraps around, sites duplicate the text in the underlying markup: two identical copies, one chasing the other. A human sees a single smooth scroll. The converter, reading the markup rather than watching the animation, sees both copies and faithfully prints them both.

The honest part: two wrong guesses before looking

This section is a candid example of the "inspect, don't guess" lesson that runs through the whole report, because here the lesson was learned the hard way. The first response to the doubling was to guess at the cause — and the guess was that a drop-down menu was responsible. A fix was written to remove that drop-down. It didn't work, because that wasn't the cause. A second guess, also aimed at the menu, was tried. It also didn't work, for the same reason. Two attempts, two deploys, no fix — all because the actual page structure hadn't been looked at.

Only when the live page was properly inspected — walking up from the doubled text through its containing elements to see what actually held it — did the real culprit appear: the text sat inside an element whose name explicitly marked it as scrolling-banner text. The moment that was known, the fix was obvious and correct. The two failed guesses weren't just wasted effort; they're the clearest illustration in this whole report of why guessing at a fix before inspecting the real structure is a false economy.

The fix

Decorative scrolling banners are removed by the patterns that reliably identify them: names containing "scrolling-text", "marquee", "ticker" or "scrolling-banner". These elements are always decorative — they're animation, not content — and they always duplicate their own text as part of how the scroll works. Removing them by pattern fixes the doubling not just on the one site that exposed it, but on any site that uses a scrolling banner of this kind. As with every fix here, the specific site was only the example that revealed the class of problem; the fix targets the pattern.

Key points

• Doubled text ("Smart Gardens Smart Gardens") came from a scrolling banner that duplicates its text for a seamless loop.
• The first two attempts guessed a drop-down menu and both failed, because that wasn't the cause.
• The real culprit was found only by inspecting the live page and walking up from the doubled text to its container.
• The fix removes marquee/ticker/scrolling-banner patterns, which are always decorative and always duplicate their text.
• It fixes the doubling for any site using such a banner, not just the one found.

How to fix duplicated text in a conversion

1. Don't guess the source — inspect the live element that actually holds the duplicated text.
2. Walk up from the text through its parent elements to find the container and its name or role.
3. If it's a scrolling banner, ticker or marquee, the duplication is by design; remove those by pattern.

How to avoid wasting deploys on guesses

1. Before writing a fix, confirm you've identified the real element, not a plausible-sounding one.
2. Inspect once, thoroughly, rather than deploying a guess and waiting to see if it worked.
3. Treat a failed fix as a signal to go and look at the structure, not to guess again.

Questions & answers

Why was the text doubled? Scrolling banners repeat their text in the markup so the animation can loop without a visible gap when it wraps. The converter reads the markup, not the animation, so it sees both copies and prints both — until the banner element is removed.

Why did the first fixes fail? They guessed the cause was a drop-down menu and removed that instead of the real element. The doubling lived in a scrolling-text banner, so removing a menu changed nothing. Two attempts were spent on the wrong element before the live page was actually inspected.

Is removing banners safe for content? Yes. Marquees, tickers and scrolling banners are decorative furniture that duplicate their own text as part of the scroll effect; they're never the page's real content. Removing them cleans the output and removes the duplication in one step.

What's the general lesson here? Inspect before you fix. The two failed guesses cost two deploys and fixed nothing, while a single proper inspection of the live element revealed the exact class to remove. Guessing at a fix before looking at the real structure is slower, not faster.

What was wrong

Some sites — shops in particular — were leaking pop-up dialogs into the Stripped output. A slide-out shopping cart, a "we use cookies" or location-consent box, an "added to your cart" confirmation that appears when you click buy. On the live page these are overlays that sit on top of the content, appearing and disappearing as you interact. In a clean content conversion they're pure noise: nobody converting a product page to Markdown wants the cookie banner and the cart drawer bundled in with it.

The awkward part is that many of these overlays are built with generic styling that carries no obvious "this is a pop-up" name. Modern sites often use utility-style CSS where the class names describe appearance (spacing, colour, position) rather than purpose, so there's no helpful "modal" or "popup" label to key on. That's exactly what let these slip through the earlier cleanup — there was nothing obvious to match.

The fix, keying on accessibility instead of class names

The key insight was that even when a pop-up has no useful class name, it almost always has a reliable accessibility marking. This isn't optional: for a screen-reader to handle an overlay correctly — to announce it, to trap focus inside it, to let a blind user dismiss it — the element has to declare itself as a dialog. So these overlays carry a "dialog" role or an "is a modal" attribute even when their visible class names are meaningless. That accessibility marking is a far more reliable signal than any style name, precisely because it's required for the pop-up to function for everyone.

So the removal targets those accessibility markers — the dialog role and the modal attribute — plus the specific structural names that shops use for cart and consent drawers. That combination catches the overlays whether or not they were given a helpful class name: the accessibility markers catch the generically-styled ones, and the structural names catch the shop-specific drawers.

The lesson: go to role and ARIA for hidden overlays

The broader lesson, which recurred later with the skip-links, is this: when a pop-up has no obvious class hook, don't sit there guessing at combinations of utility classes. Go straight to its accessibility role and attributes. Those markers exist precisely to identify the element as an overlay, for the benefit of assistive technology, and that makes them the most dependable thing to match on. Guessing at style names is slow and site-specific; matching the accessibility contract is fast and general.

Key points

• Cart drawers and consent/location modals leaked into Stripped, some with no obvious pop-up class name.
• The reliable signal is the accessibility marking — a dialog role or an "is-modal" attribute — which overlays must carry to work for screen-readers.
• Removal targets those accessibility markers plus shop-specific cart and consent drawer names.
• The lesson: for hidden overlays, inspect the accessibility role and attributes rather than guessing class names.
• It's safe: a dialog role always marks an overlay, never the page's main content.

How to remove overlays reliably

1. Check the accessibility role and modal attributes first — overlays carry them so assistive tech can handle them.
2. Add the known structural names for cart drawers and consent boxes on top of that.
3. Confirm real content isn't caught, since a dialog role marks furniture, never article content.

How to find an overlay with no useful class

1. Walk up from the overlay's visible text through its containers, noting role and ARIA attributes, not just classes.
2. Look for the dialog role or modal attribute the overlay needs for accessibility.
3. Use framework-specific section ids where they exist, as a stable hook the class names don't provide.

Questions & answers

Why did some pop-ups have no useful class name? They were built with utility-style CSS, where class names describe appearance rather than purpose, so there was no "modal" or "popup" label to match. Their only reliable identifier is the accessibility role or attribute that marks them as a dialog for assistive technology.

Is removing dialogs ever going to drop real content? No. A dialog role marks an overlay — a cart, a consent prompt, an alert — that sits on top of the page. It's never used for the page's main content, so removing elements with that role only cleans the output and never touches the article.

Why is the accessibility marker more reliable than the class? Because it's not optional. For an overlay to work for screen-reader users it must declare itself a dialog and flag itself as modal; those markers are part of the accessibility contract. Class names are free-form and often meaningless, but the role and modal attribute are dependable precisely because the pop-up needs them to function.

What about shop drawers with neither a class nor a role? Those are caught by their framework's structural section ids — the stable identifiers a platform gives its cart and consent components. Where class and role both fail, those ids provide the hook, which is how the cart and geo-consent drawers were caught.

What was wrong

"Skip to content" links were leaking into the output. These are the small accessibility shortcuts that let a keyboard user jump straight past the navigation to the main content — genuinely useful on a live page, and a mark of a well-built site. But they are navigation aids, not content, so in a clean content conversion they don't belong. Finding "Skip to Content" at the top of a converted article is a small leak, but a persistent and visible one.

Skip-links turned out to be one of the more stubborn kinds of chrome to remove completely, not because any one of them is hard, but because they're built so inconsistently from site to site. Catching all of them took three separate layers, each added because the previous ones missed a real case found in testing.

Why one rule was never going to be enough

Some skip-links are easy: they carry a helpful name like "skip-link" or "skip-to-content", and a rule keyed on that name catches them cleanly. But many don't. Some have no useful name at all, and can only be recognised by their text — a link whose words begin "Skip to". And then there's the hardest case, found on Magento: the skip text is wrapped in a bare, nameless element that isn't even a link. It has no skip-link class, no link address, nothing that the first two rules look for — just the words "Skip to Content" sitting in a plain container. That one slipped through both earlier layers and kept leaking as plain text.

The fix, in three layers

So skip-links are removed three ways, and all three are needed. First, by name: anything explicitly marked as a skip-link is removed. Second, by behaviour: any actual link whose visible text begins "Skip to" is removed, catching the ones with no helpful name. Third, by exact phrase in a bare element: any plain element whose entire text is one of the standard skip phrases — "Skip to content", "Skip to main content", and the handful of close variants — is removed, which finally catches the Magento nameless-span case. Together the three layers catch every variant found across all the platforms tested, whatever the site's markup.

An honest note on how the last one was found

The Magento variant wasn't found by luck. It surfaced because every platform was being tested systematically, and one stubborn leak remained after the first two layers were in place. Rather than guess at it, the live element was inspected — which revealed it was a bare, nameless container holding the skip text, not a link at all. That inspection is what explained why the earlier layers missed it and pointed directly at the third layer needed to catch it. It's the same inspect-don't-guess discipline, applied to the last remaining leak in the whole effort.

Key points

• "Skip to content" accessibility links leaked into output, and are built inconsistently across sites.
• Catching them took three layers: by skip-link name, by "Skip to" text on a real link, and by exact phrase in a bare element.
• Magento wraps the skip text in a nameless, non-link element that the first two layers missed.
• The Magento case was found by systematically testing every platform and inspecting the one remaining leak.
• The exact-phrase rule matches only standard skip phrases, so it can never hit real content.

How to remove skip-links reliably

1. Remove by explicit skip-link naming wherever it exists — the easy, common case.
2. Add a behaviour rule for links whose visible text begins "Skip to", catching the unnamed ones.
3. Add an exact-phrase rule for bare elements, since some platforms use a nameless container.

How to make a phrase-based rule safe

1. Match the entire text of the element, anchored start to end, not a substring anywhere in it.
2. Restrict to the closed set of standard accessibility phrases, so ordinary content can't match.
3. Test against a content-rich page to confirm nothing legitimate is removed.

Questions & answers

Why do skip-links need removing at all? They're keyboard-navigation shortcuts — useful on the live page but not part of its content. In Stripped mode, which promises content-only output, they're furniture and get removed, just like the navigation they're designed to help you skip past.

Why did Magento's slip through the first two rules? Because Magento wraps the skip text in a plain, nameless container that isn't a link. The first rule looks for a skip-link name it doesn't have; the second looks for a link, which it isn't. Only an exact-phrase rule on a bare element catches it.

Could the exact-phrase rule remove real content? No. It matches only the exact standard accessibility phrases — "Skip to content", "Skip to main content", "Skip to navigation" and close variants — anchored to the whole text of the element. Real content isn't a lone element whose entire text is exactly one of those phrases.

How was the last leak found without guessing? By testing every platform systematically until one leak remained, then inspecting that live element rather than guessing. The inspection showed a bare classless container holding the phrase, which both explained the miss and pointed at the exact rule needed.

What appeared to be wrong

A test suggested numbered lists were being mishandled — either lost or inflated. The count of numbered-list items in the output didn't line up with what a glance at the page suggested was there, and a mismatch like that reads as a conversion fault: either the tool is dropping list items, or it's inventing extra ones. Both would undermine trust in the output, so it needed running down properly rather than being noted and ignored.

What was actually happening: mostly a false alarm

The mismatch was mostly a false alarm, and the reason is a quirk of how modern site builders work. Several of them — Squarespace prominent among them — use numbered-list markup to build things that aren't visible numbered lists at all. A post carousel, a slider, a category block: under the surface these are frequently constructed from the same markup a numbered list uses, and they often duplicate their slide text so the carousel can loop. So when the converter reported more numbered-list items than the eye expected, it wasn't inflating anything — it was accurately counting real numbered-list markup that the site happened to use to build a slider. The count was faithful to the markup; the markup just wasn't a visible list.

Once that was understood, the "loss or inflation" concern largely dissolved. The converter was doing exactly what it should: reading the markup as written and representing it accurately. The mismatch was between the markup and a human's visual impression of the page, not between the input and the output.

The one genuine edge

There is, however, a single real edge worth documenting honestly rather than glossing over. When a numbered list is nested deep inside another list — specifically, a numbered list sitting inside a bullet point that itself sits inside another list, a structure seen in a Joomla download-steps block — the inner numbering (1., 2., 3.) can get absorbed into the parent bullet in Stripped mode. The content is all still there; every step's text is kept. What's lost is only the inner numbering, which flattens into the parent bullet rather than appearing as a distinct numbered sequence.

This is a real, if minor, imperfection. It was not rushed into a fix, and that decision is deliberate. The change needed to correct it sits in the core list-rendering logic that every conversion depends on, so a careless change there risks regressions across every page the tool handles. Given the content is fully preserved either way — only the numbering formatting is affected in one uncommon nesting pattern — the honest choice was to document it clearly as a known edge rather than risk a broad regression for a narrow cosmetic gain.

Key points

• The "lost or inflated numbered lists" concern was mostly a false alarm.
• Site builders use numbered-list markup to build sliders and carousels that duplicate text; the converter's count was accurate.
• The mismatch was between the markup and a human's visual impression, not between input and output.
• One genuine minor edge: deeply nested numbering can flatten in Stripped — content kept, numbering absorbed into the parent bullet.
• That edge sits in core list-rendering logic, so it's documented honestly rather than rushed into a regression-risky fix.

How to judge a "list count" mismatch

1. Check whether the numbered-list markup is actually a visible list, or a slider/carousel built from list markup.
2. If it's a slider with duplicated slides, an accurate count will look inflated but is faithful to the markup.
3. Compare the output to the underlying markup, not to your visual impression of the rendered page.

How to decide whether to fix a rendering edge

1. Establish whether content is actually lost, or only formatting — the two carry very different urgency.
2. Weigh the regression risk of changing shared, core logic against the narrowness of the gain.
3. Where content is preserved and only cosmetics suffer in a rare case, document the edge rather than risk a broad regression.

Questions & answers

Were numbered lists actually lost? No. In the flagged cases the markup was a slider or carousel built from list tags with duplicated slide text, so the converter's count was faithful to the markup rather than a fault. Nothing was dropped; the markup simply wasn't the visible list a human expected.

What's the one real issue, then? A numbered list nested inside a bullet inside another list can lose its inner numbering in Stripped mode. All the text of every step is kept; only the 1./2./3. numbering flattens into the parent bullet. It's a formatting imperfection in an uncommon nesting pattern, not content loss.

Why not just fix it? Because the change needed lives in the core list-rendering logic that every conversion uses, where a careless edit risks regressions across all pages. Since the content is preserved and only the numbering formatting is affected in a rare structure, it was documented honestly rather than changed hastily.

How common is the nested-numbering case? Uncommon — it needs a numbered list inside a bullet inside another list, which is a specific structure seen in things like step-by-step download instructions. Most pages never hit it, which is part of why a broad, regression-risky fix wasn't justified for it.

The situation

Many web pages carry structured data — a machine-readable summary, tucked into the page, that describes what the page is about: this is a product, with this price and this rating; this is an article, by this author, published on this date; this is a recipe, with these ingredients. Our Markdown Generator reads that structured data and adds a tidy summary of it to the output, which is genuinely useful for an AI trying to understand the page at a glance.

The catch is that structured data is only useful if it's valid, and a surprising number of real sites ship structured data that is broken — malformed, with a syntax error that makes it unreadable. A naive tool, encountering that, would choke: it would try to read the broken data, fail, and either crash or spit an error into the output. Since the whole point of the generator is to work on the real, messy web rather than a tidy laboratory version of it, how it behaves when it meets broken structured data is a real test of its robustness.

What we confirmed on a real broken page

The test used a genuinely broken real page: a BigCommerce product page (an Oral-B toothbrush listing) whose structured data was invalid — it contained a value that wasn't properly formatted, breaking the whole block. The generator did exactly the right thing. It attempted to read the structured data, recognised that it couldn't be parsed, quietly skipped just the summary for that one page, and produced all the rest of the Markdown perfectly — every heading, every paragraph, every piece of content, entirely intact. The only trace of the problem was a single note written to our own server log, for our visibility. The user's output was clean and complete, with no error in it and no missing content.

Why this is the right behaviour

This is graceful degradation, and it's exactly what you want. When the tool meets structured data it can't read, it doesn't crash, it doesn't lose the page's content, and it doesn't leak a technical error into the user's output. It simply skips the one part it couldn't read — the summary — and carries on with everything else. The broken data belongs to the source site and isn't ours to repair; the correct response is to tolerate it, take what can be taken, and never let one site's malformed markup spoil the conversion of its content.

It's also worth being clear about where the error message goes. The note about the parse failure is written to the server log, which only we see. It never appears in the Markdown the user receives. That separation — diagnostics for us, clean output for the user — is deliberate and holds throughout the tool: the user's output is content and nothing else.

Key points

• Many real sites ship invalid structured data that would break a naive converter.
• On a real broken BigCommerce page, the generator skipped only the summary and produced all the content correctly.
• The parse error goes to the server log only — it never appears in the user's output.
• The broken data belongs to the source site; the correct response is to tolerate it, not crash or repair it.
• Confirms the tool degrades gracefully on the messy real web, which is what it's for.

How to handle broken structured data

1. Attempt to read the structured data, but wrap the parsing so a failure is caught, not fatal.
2. On failure, skip only that page's summary — never the page content.
3. Log the error server-side for your own visibility; never surface it in the user's output.

How to prove graceful degradation

1. Find a real page whose structured data is genuinely malformed, not a synthetic one.
2. Confirm the content still converts in full — check the heading and byte counts.
3. Confirm no raw structured-data or error text leaked into the output.

Questions & answers

Does broken data lose me content? No. Only the machine-readable summary is skipped for that one page. Every heading, paragraph, list and image still converts normally, so the page's actual content comes through in full even when its structured data is unreadable.

Will I see an error in my output? No. The parse failure is logged on our server for our own visibility, outside anything the user receives. Your Markdown output stays clean, with no error text and no raw structured-data fragments in it.

Why not just repair the broken data? Because automatically repairing arbitrary malformed structured data is unreliable and could invent information that isn't really there. Skipping the unreadable summary while keeping the content is safe and predictable; guessing at a repair would risk putting wrong data into the output.

Whose fault is the broken data? The source site's — it's their markup, and it's not ours to fix. The right behaviour is to tolerate it: take the content, skip the part that can't be read, and never let one site's malformed markup break the conversion of its own page.

What was missing

Pages with embedded video weren't being represented in the Markdown at all. A video is real content — often the main content of a page — so silently dropping it misrepresents what the page actually offers. Someone converting a tutorial page built around a video would get the surrounding text but no acknowledgement that the video, the centrepiece, was even there.

The difficulty is that Markdown is a text format: it can't play a video. So "capturing" a video can't mean embedding a playable player. It has to mean representing the video faithfully in text — acknowledging that it exists and pointing at where it lives.

What was added

The generator now handles embedded video by capturing two things: the video's preview image — the poster frame that shows before you press play — and a link to the video's source. Between them, these represent the video honestly in a text format: the poster gives a visual sense of what the video shows, and the source link points to the actual video. So a page's video is now acknowledged in the output rather than vanishing without trace, and it's represented in the only way a text format sensibly can.

Why this is the faithful approach

Capturing a poster and a source link, rather than trying to do something cleverer, is the honest representation of a video in Markdown. It doesn't pretend the video can play in text, and it doesn't drop it as if it weren't there. It records that a video exists, shows its preview, and says where to find it — which is exactly what a reader or an AI needs to know about a video they're encountering as text. The handling was added to the shared conversion machinery, so it applies consistently across all three modes.

Key points

• Embedded video was previously not represented in the Markdown at all.
• The generator now captures the video's preview image and a source link.
• Video is treated as real content, so it's acknowledged, not silently dropped.
• Poster-plus-link is the faithful way to represent a video in a text format.
• Added to the shared conversion machinery, so it applies across all three modes.

How to represent video in a text conversion

1. Capture the poster/preview image so the reader has a visual sense of the video.
2. Capture a link to the video source so the video itself can be found.
3. Add the handling to shared conversion logic so every mode treats video the same way.

Questions & answers

Does it embed the whole video? No — Markdown is text and can't play video. It captures the poster image and a link to the source, which is the faithful way to represent a video in a text format: a visual preview plus a pointer to the real thing.

Why represent video at all? Because it's genuine page content, often the main content. Dropping it silently would misrepresent the page as text-only. A poster and source link preserve the fact that the video exists and show where it points.

Why capture the poster specifically? The poster is the frame the site shows before playback, so it's the best single still to convey what the video is about. Paired with the source link, it gives a reader or an AI both a visual sense and a way to reach the full video.

Does this apply to all three modes? Yes. The video handling was added to the shared conversion walker that all three modes use, so Full, Stripped and Custom all represent an embedded video the same faithful way.

The headline result

After every fix described in the sections above was in place and deployed, the whole thing needed proving — not on a hand-picked handful of pages, but comprehensively. So the finished converter was run against every real page gathered across the entire effort: 219 distinct pages, drawn from all eleven supported platforms, deduplicated and filtered down to substantial pages. Each one was put through both Full and Stripped conversion and checked for any chrome leak or converter error.

The result was clean across the board: 219 pages tested, zero converter errors, zero chrome leaks. All clean. Every page converted without a crash, and not one of them let a scrap of navigation, a pop-up, a scrolling banner, a skip-link or a tracking frame through into the Stripped output.

Why this is the proof that matters

This is the strongest evidence in the whole report, and the reason is what the 219 pages actually are. This isn't a curated sample chosen to look good. It's the entire corpus of real pages collected while finding and fixing every issue described above — the messy, real-world pages that exposed each leak in the first place. These are the hardest pages the tool has faced, the ones that broke earlier versions and forced each fix into being.

Running the finished converter against all of them, and getting zero leaks and zero errors, is exactly the test that distinguishes a set of general fixes from a pile of site-specific patches. If the fixes were narrow patches, some of these pages would still leak. They don't. That's what proves the fixes generalised — that removing "the scrolling banner on that one site" actually became "remove scrolling banners everywhere", and so on for every fix in this report.

The only output

The single thing the run produced besides "all clean" was the graceful-degradation log line for the two BigCommerce pages with broken structured data — the exact safe behaviour described in the structured-data section. On those pages the summary was skipped, the content was preserved in full, and the note went to the server log only. Nothing leaked into any user's output. So even the one non-blank line the test produced is itself a confirmation of correct behaviour, not a problem.

Key points

• The finished converter was run against all 219 distinct real pages from every platform, deduplicated and size-filtered.
• Result: zero converter errors, zero chrome leaks — every page clean.
• This is the whole corpus, not a sample — the exact real pages that exposed each issue in this report.
• A clean run across those hardest pages is what proves the fixes are general, not site-specific patches.
• The only log output was the safe broken-structured-data note on two pages — itself a confirmation of correct behaviour.

How to run a definitive corpus test

1. Gather every real page collected across the whole effort, deduplicated and filtered to substantial pages.
2. Run the finished converter over all of them, in both Full and Stripped mode.
3. Flag any chrome leak or error; a clean run across the full corpus is your proof the fixes generalised.

How to make a corpus test trustworthy

1. Test the deployed converter itself, not a separate copy that could drift from production.
2. Include the hardest pages — the ones that exposed the bugs — not an easy sample.
3. Check for both crashes and leaks, and account for every non-blank line the run produces.

Questions & answers

Why 219 and not a round number? Because it's every distinct real page actually collected across the effort, after removing duplicates and tiny pages — not a target chosen for neatness. The number is simply whatever the real corpus came to once deduplicated and filtered.

Isn't testing on the pages that found the bugs circular? No — it's the opposite of circular. Those are the hardest, messiest real pages, the ones that broke earlier versions of the converter. A finished converter passing all of them proves the fixes generalised to the whole class of problem rather than patching one case each.

What about the two log lines? Those are the two BigCommerce pages with broken structured data degrading gracefully — summary skipped, content kept, note to the server log only. They never touch the user's output, so they're expected, safe, and actually a confirmation that the graceful-degradation behaviour works.

How do you know it tested the real tool? The test loads the actual converter functions from the deployed code and runs those, rather than a separate reimplementation. There's nothing that could have drifted from what's live, so a clean result reflects the converter users actually get.

Two more tests, to be thorough

The 219-page corpus test proves the converter is clean across platforms. But two further tests pushed on the specifics, to make sure nothing had been missed at the edges — a particular platform, or a particular kind of page.

Eight pages per platform

The first was a structured sweep: eight real pages on each of the eleven platforms — 88 pages in total — run through the converter and checked for leaks. The result was zero chrome leaks across every one of the eleven platforms. This sweep is also where the very last leak in the entire effort was caught: the Magento bare-span skip-link described earlier. It showed up as the single remaining leak in an otherwise clean run, was inspected, understood, and fixed — after which the sweep came back completely clean. That's the moment the leak count for the whole project reached zero.

One distinct site per content type, per platform

The second test asked a harder question. Homepages are one thing, but the converter needs to handle specialised pages too — and a homepage exercises very different markup from a recipe page, a product page, an FAQ, or a page full of data tables. So the server was set to discover, for each content type on each platform, a distinct real site featuring that type: an FAQ page here, a product page there, a recipe, an events listing, an article, a page with forms, a page with tables, one with tabbed sections, one with breadcrumbs. Each cell in that grid was filled by a different real site the server found and verified, and every one was run through the converter.

Of the pages that successfully fetched, every single one converted clean — zero leaks, zero errors. The only misses were a small number of affiliate-redirect links that didn't return a real page at all, which is a fetch failure rather than a converter fault: there was simply no page to convert. Every page that actually loaded came through clean.

What this establishes

Together these two tests establish something the corpus test alone couldn't: that the generator produces clean Markdown not just on any platform, but on any kind of page. A recipe on a food blog, a product on a shop, an FAQ on a help site, a table of data, a page built around forms — whatever the content type, whatever the platform underneath it, the output is clean. Between the 219-page corpus, the eight-per-platform sweep, and the distinct-site-per-type grid, the converter has been proven across the two dimensions that matter: the platform a site is built on, and the kind of content a page holds.

Key points

• An eight-per-platform sweep (88 pages) returned zero leaks across all eleven platforms.
• The last leak in the whole effort (the Magento skip-link) was caught and fixed in this sweep, bringing the project's leak count to zero.
• A distinct site per content type per platform was discovered and tested — FAQ, product, recipe, events, article, forms, tables, tabs, breadcrumbs and more.
• Every page that fetched converted clean — zero leaks, zero errors; the only misses were dead affiliate-redirect links.
• Together the tests prove clean output across both platform and content type.

How to test content-type coverage

1. Have the server discover a distinct real site for each content type on each platform, so each cell is a different site.
2. Run the converter over each and check for both leaks and errors.
3. Treat failed fetches (dead redirects) separately from genuine converter faults.

How to close out a leak-fixing effort

1. Sweep every platform systematically until any remaining leak stands out as a single case.
2. Inspect that last case rather than guessing, fix it, and re-run to confirm the sweep is clean.
3. Add a content-type dimension so specialised pages, not just homepages, are covered.

Questions & answers

Why test content types separately from platforms? Because a homepage exercises very different markup from a recipe, a product page or a data table. Testing each content type proves the converter is clean on the specialised pages people actually convert, not just on landing pages, which is a different guarantee from platform coverage.

What were the failed fetches? A few of the sites the server discovered were reached through affiliate-redirect links that didn't return a real page. That's a fetch miss, not a conversion fault — there was no page to convert. Every page that actually loaded converted clean.

Were the sites genuinely distinct? Yes. Each content-type cell was filled by a different real site the server found and verified, tracked so that once a site was used it wasn't reused. That spreads the test across a wide range of independent pages rather than pulling many content types off one convenient site.

What did the eight-per-platform sweep add over the corpus test? It guaranteed even coverage — a fixed eight pages on every platform, so no platform could be under-represented — and it was the sweep that surfaced the final Magento skip-link leak. It's the test that drove the project's leak count to a confirmed zero.