Monolith – CLI tool for saving complete web pages as a single HTML file

Original Article ↗ Hacker News Discussion ↗

Developers are exploring new tools for saving complete web pages into a single, portable file as a more reliable alternative to browser “Save page” features, which often break layouts or scatter assets across folders. Projects like Monolith and SingleFile take different approaches—Monolith embeds assets without executing JavaScript, while SingleFile drives a real browser engine for higher-fidelity captures—highlighting trade-offs between speed, compatibility, and complexity. Participants also connect these tools to broader needs like personal knowledge bases, offline reading, long-term archival (including MHTML and WARC formats), and workarounds using headless browsers and services such as ArchiveBox or Omnivore.

Browser support for saving pages

  • Older browsers (e.g., IE5) and current ones (Firefox, Chrome, Safari) can save pages, but results are often messy: HTML + asset folder, broken CSS/JS, or proprietary formats like .webarchive.
  • MHTML used to be widely supported and is still in Chrome, but support has regressed or is inconsistent across browsers and mobile.
  • Several comments express surprise that robust, portable single-file saving is still not a first-class browser feature.

Monolith vs. other tools

  • Monolith: Rust CLI that inlines all assets as data URIs in a single HTML file, no JS engine. Good for exact static snapshots when JS isn’t needed. Limited to one page at a time.
  • SingleFile / single-file-cli: browser extension and CLI that use a real browser engine, capture post-JS DOM, support ZIP/self-extracting formats, and usually yield high-fidelity results. Slower and heavier, but handles JS-heavy sites and authenticated pages.
  • Other tools mentioned: wget (recursive archiving), ArchiveBox (self-hosted archiver), headless Chrome/Playwright and utilities like shot-scraper, WARC-based approaches, and various paid screenshot APIs.

Use cases and workflows

  • Personal knowledge bases: saving every interesting article, Q&A, or forum thread; organizing via folders, search tools, and syncing to note systems (e.g., Joplin, Obsidian).
  • Long-term archiving: combating link rot in bookmarks, news sites, and blogs; using ArchiveBox or Wayback Machine helpers alongside local archives.
  • RAG/LLM workflows: feeding years of saved HTML into local indexing pipelines.
  • Ideas for one-click browser → Monolith/SingleFile → notes integration, and mobile workflows via browsers that support extensions.
  • Questions about archiving entire apps (e.g., Redmine instances) and restoring sites from Wayback; suggestions include recursive tools and ArchiveTeam docs.

Technical and UX challenges

  • JS-driven sites, infinite scroll, cookie/paywall overlays, headless-browser detection, and popup banners complicate archiving and screenshots.
  • Workarounds include injected JS (scrolling, removing overlays, accepting banners), ad-blockers, custom wait conditions, and UA/feature spoofing.
  • Debate over formats: data URIs vs. MHTML vs. WARC; trade-offs in size, fidelity, binary support, and browser compatibility. MHTML support in Monolith is planned but incomplete.
  • Concerns about embedded JS in saved pages (tracking, auth behavior) and about ever-increasing web complexity making faithful local copies harder.

Broader reflections

  • Many note alarming web decay and see tools like Monolith/SingleFile as essential preservation infrastructure.
  • There’s frustration at modern browsers “regressing” on archival features and enthusiasm for small, fast, Rust-based CLI tools that fill the gap.