Saving a Page as a Safari Web Archive for UnHTML Import

Yes. A Safari Web Archive is one of the three file types UnHTML takes directly: drag the .webarchive file into the plugin the same way you'd drop in a self-contained .html file, no CLI setup, no bookmarklet to install first. The catch is everything that happens before that drag: what a .webarchive actually captures, how it differs from a plain HTML save, and when it captures enough of a page for the import to be worth doing at all.

What a .webarchive file actually is

A .webarchive bundles a page's HTML plus its linked CSS, JavaScript, and images into one file. That's the whole difference from a bare .html save, which keeps only the markup and leaves every linked asset behind, waiting to 404 the moment you open that file somewhere else. A Web Archive stores those concatenated source files in binary plist form, serialized with NSKeyedArchiver, and its Windows support was dropped back in 2012. Today it's created and read on Apple platforms only: macOS and iOS or iPadOS. If you're handing a file to a teammate on Windows, that matters: their Safari (if they still have one) can't open it, so a Mac or iOS device stays the natural place to double check the file before importing.

The reason nested content survives the trip is structural, not incidental. WebKit's WebArchive object holds a main resource plus its subresources and subframe archives, and each nested frame carries its own bundled assets rather than pointing back out to the live page for them. Copy a bare HTML file instead, and an embedded iframe, an inline video player, or a third-party widget usually goes missing the moment you open that file anywhere but the original tab.

That matters for an import. A page you want to rebuild in Figma is rarely one flat document. Marketing pages routinely embed a video player, a scheduling widget, or a comparison table served from a different origin, all as an iframe. A .webarchive keeps that content attached to the file. A bare HTML export does not.

Saving a Web Archive on Mac

Prerequisite: Safari on macOS, open to the page you want to capture.

1. Open the page in Safari and let it finish loading, including anything that lazy-loads on scroll.
2. Choose File, then Save As.
3. Under Format, choose Web Archive. Page Source only keeps the raw markup, and Web Page, HTML Only strips out most of the linked assets, so neither one bundles a page the way Web Archive does.
4. Save, and note the destination folder so you can find the file again for the import step.

Apple describes the saved copy as keeping its links working only as long as the destination pages stay online: it's a snapshot of the page as rendered at save time, not a fully self-contained mirror of every page a link points to. For an import, that distinction rarely matters. UnHTML only needs the page you saved, not everything that page links out to.

Saving a Web Archive on iPhone or iPad

Prerequisite: Safari on iOS or iPadOS 13 or later.

1. Open the page in Safari and let it finish loading.
2. Tap the Share icon.
3. Choose Save to Files, and pick a location you can reach from a Mac afterward, such as iCloud Drive or a synced folder.
4. Confirm the save, then move the file to your Mac once you're ready to import it.

The mobile path exists mainly for pages you only ever encounter on a phone or tablet: a competitor's landing page loaded through an app link, a promotional email that only opens on mobile Safari, or a layout that renders a genuinely different design at its mobile breakpoint. Once the file lands on a Mac, importing it works exactly the same as any other .webarchive, no matter which device created it.

Importing the .webarchive into UnHTML

UnHTML takes exactly three input types, dropped straight into the plugin: a self-contained .html file, a Safari .webarchive, or a scene.json captured with its own open source CLI or bookmarklet. It doesn't fetch a live URL on its own. Something has to capture the page first, and a .webarchive is the fastest capture that needs no setup at all: no CLI to install, no bookmarklet to drag into a bookmarks bar.

A .webarchive is enough when the page's content is already present in the DOM at the moment you save it: marketing pages, documentation, most blog posts and long-form articles, pricing tables rendered server side. Where it falls short is anything that keeps rendering after the initial load. A single-page app built on React or Vue, or a page pulling assets from a different origin, can freeze mid-render in a saved snapshot or lose cross-origin (CORS) content entirely. That's exactly the gap UnHTML's own CLI or bookmarklet exists to close, capturing a JavaScript-rendered site instead as a scene.json file with the fully rendered state and remote assets already resolved.

Here's a quick way to check before you import: reopen the saved .webarchive offline. Looks identical to the live page? The import should go cleanly. Sections blank, images missing? Reach for the CLI capture instead of the file save.

Once the import runs, UnHTML converts CSS layouts into native Figma auto layout for flex, grid, and block displays where it can. The free tier caps an import at 500 layers and falls back to absolute positioning past that. Removing the cap and getting full auto-layout conversion on larger pages is what the paid tiers add.

A common case for this whole flow: tearing down a competitor's pricing page to see how it's put together. That page is usually server-rendered enough that a .webarchive captures it in full, tables, icons, and all, so there's rarely a reason to reach for the CLI here. Now compare that against a marketing site built on a JavaScript framework, where the pricing table only appears after a client-side fetch. Saving that page with File, Save As often freezes the capture before the table renders, leaving an empty section once the file is reopened. That's the signal to switch to the CLI or bookmarklet capture instead.

What still does not survive the trip

Even a clean .webarchive import has limits, and UnHTML lists them in its import report rather than leaving you to discover them later.

Any font that isn't installed locally gets substituted, Inter by default, and every substitution is listed in that report so nothing swaps silently while you're not looking. If a page leans on a licensed display font you don't have installed, expect to see it flagged there rather than rendered as intended. See how missing fonts get substituted and logged for the full mechanics.

Layout is the other place things can shift. Complex CSS grid layouts that can't map cleanly to Figma's auto layout fall back to absolute positioning instead. The result is a faithful, editable set of layers, not an exact clone of the original page, and that honesty is deliberate: the import report is where every font swap and layout fallback gets listed, so you know precisely what to check before you start editing, not after.

Conclusion

A Safari Web Archive is the fastest way to hand UnHTML a real snapshot of a page: save it from the File menu on Mac or the Share sheet on iOS, then drag the file straight into the plugin. It works well for anything already rendered by the time you saved it. For pages that keep rendering client side after load, the CLI or bookmarklet capture remains the more dependable path. Either way, the import report tells you exactly what made it through intact and what got substituted along the way.