The redaction guarantee

When you redact a region of a demo, the promise you actually want is not "it looks hidden" — it's "the content is not there for anyone to recover." DemoMate is built so a published demo enforces that promise in the served bytes, and so you can check it yourself without trusting our word for it.

This page is precise about which redaction mode removes what, because honesty here is the whole point: one of our two modes is a real removal, and one is a cosmetic cover. We tell you which is which so you can pick the right one.

What "redaction" means here

DemoMate captures a real page — either its live HTML/DOM or a screenshot — and you edit that capture in the demo editor. Redaction is one of those edits. It has two modes, and they behave differently depending on what the step captured.

The single rule that follows from this table:

To make sensitive text unrecoverable on a live-DOM step, use Black out, not Blur. Blur on a DOM step is a visual effect, not a removal — the text is still in the source. On a screenshot step, both modes are destructive, because a screenshot has no text to leave behind, only pixels.

The editor says the same thing at the point you choose a mode: Black out is described as removing each covered element's whole text "gone from the source," and Blur is described as "reversible, but the text stays in the page source."

What happens at publish

Editing a demo never touches the original capture. The raw snapshot you captured is stored once and is never mutated — that is what makes every edit undoable while you are still working on a draft.

Your redactions are applied when the demo is served, and they are made permanent when you publish:

• Live-DOM steps. On publish, the redaction edits are baked into the sanitized HTML that goes into the published version. For a Black out, the covered elements' text is stripped from that HTML. The published bytes simply do not contain it.
• Screenshot steps. A screenshot's redaction cannot be a text removal — there is no text, only an image. So on publish the blur or black-out is baked into the image pixels, producing a brand-new image file, and the original screenshot is dropped from the published bundle entirely. The published demo references only the baked image; the source image is never uploaded to the version anyone can reach.

If DemoMate ever cannot read a screenshot's dimensions to place a redaction reliably, the publish fails rather than shipping the original image — a redaction never silently degrades into "we published the untouched picture."

The practical consequence: a viewer, a browser extension, a crawler, or someone opening DevTools on a published demo has nothing to recover for a Black out (DOM) or any screenshot redaction. The content is not hidden by CSS or layered under an overlay — it is absent from what we sent.

Unlike overlay-style blurs

Some demo tools redact by drawing a blur or a box on top of the captured content while the original text and images stay underneath in the page. That is a cosmetic layer: the sensitive data is one "View Source" or one removed CSS rule away. Tools that work this way generally advise, in their own documentation, not to capture sensitive data in the first place — which is a fair warning, because their blur is a cover, not a removal.

DemoMate's Black out and its screenshot bake are removals, not covers. This is exactly why we are careful to label our own Blur on a DOM step as cosmetic: it is an overlay-style blur, and pretending otherwise would be the same overclaim we are contrasting against. For anything that must not be recoverable, reach for Black out (or redact on a screenshot step).

Verify it yourself

You do not have to trust this page. Publish a demo, open it, and check:

1. View Source. On a published DOM step, open your browser's "View Page Source" (or DevTools > Elements) and use in-page find (Cmd/Ctrl-F) to search for the exact text you blacked out. On a Black-out redaction, you get zero hits — the string is not in the document. (Search for text you only Blurred on a DOM step and you will find it, which is the honest confirmation that Blur is cosmetic.)
2. Inspect the assets. On a published screenshot step, open the image the step loads (right-click > "Open image in new tab," or the Network tab). It is the baked image — the redacted region is flattened into the pixels. The original screenshot is not among the published files; there is no URL for it.
3. Search the exported file. A single-file .html export is rendered from the published version, so it carries the same baked bytes. Open the exported file in a text editor and search for the redacted string — same result as View Source.

Nobody can print these instructions unless their redaction is genuinely destructive. That is the point.

Honest boundaries

We would rather you know the edges than be surprised by them.

• Drafts keep the originals — on purpose. While a demo is a draft, the raw capture is retained so your edits stay reversible and the editor can show you what you are redacting. Redaction becomes destructive in the published version. If you captured something you never want stored at all, re-capture without it rather than relying on redaction of the draft.
• Blur on a DOM step is cosmetic. Restating it because it matters: on a live-DOM step, Blur leaves the text in the source. Use Black out for text that must not be recoverable.
• Exports carry the baked bytes but not the access controls. An exported .html file contains the same destructively-redacted content as the published demo — the redaction travels with the file. What does not travel is any password, email, or expiry gate on your share link; an exported file plays offline and is ungated. See Share-link gates & export policy for that distinction.
• Deleting a demo takes it down immediately, and purges it permanently after 30 days. When you delete a demo, its live share pages are replaced right away with a "This demo has been removed" page and the cached copies are purged, so the content stops serving at once. The demo sits in Recently deleted for 30 days, during which you can restore it; after that a scheduled sweep permanently deletes its stored files and records. Restore is possible only inside that window.

What we do not claim

We describe what the code does and nothing more. We do not claim a formal security certification (for example SOC 2) on this page — that is a separate, dated commitment, not something a redaction feature earns. There is no "military-grade" anything here. The redaction guarantee is a specific, checkable property: for a Black out on a DOM step, and for any redaction on a screenshot step, the content is absent from the published bytes — and you can verify it in your own browser.