Save The Balloon

What Save The Balloon Actually Does

Most "save page" tools produce a broken mess. They grab the HTML, drop the CSS somewhere you can't find it, and leave all the image links pointing back to the original domain. Save The Balloon handles the boring part — resolving relative URLs, pulling images, stylesheets, scripts, and fonts into a local folder, and rewriting every link so the page opens correctly offline. It's not fancy. It just works on the vast majority of static pages. I used to rely on the built-in browser "Save As" feature for years. Then I started working with client deliverables where pages had to load from a shared network drive with no external internet access. That's when I actually sat down and learned what Save The Balloon does differently. The difference isn't dramatic at first glance, but after your third broken PDF or missing stylesheet, it matters.

Save The Balloon Download and Installation

The download page is straightforward — grab the latest release for your operating system from their GitHub repository. No account required. Install it, and you're mostly ready to go. There's a CLI version and a GUI version. I use the CLI because I tend to batch-save pages while doing other work, and scripting it is faster. On Windows, it drops into your PATH after installation. On macOS and Linux, you'll want to verify the binary is executable. One thing the docs don't emphasize enough: if you're on a managed corporate machine, you may need to adjust your firewall rules. The tool makes outbound connections to fetch every asset on the page, and some endpoint security software will flag that behavior immediately.

How It Actually Works Under The Hood

Here's the part nobody explains clearly. Save The Balloon doesn't just scrape a page. It loads it in a headless browser instance, waits for the DOM to settle, then crawls every resource reference it finds — images, stylesheets, scripts, web fonts, even embedded iframes. It downloads each one, stores it in a parallel directory structure, and rewrites all the source paths in the HTML to point locally. The result is a self-contained folder you can zip up, move anywhere, and open in any browser. The key technical detail most people miss: it respects the original site's folder structure by default. If images lived in /assets/img/ on the server, they'll end up in local_folder/assets/img/ on your machine. This matters because some older pages reference sibling files relative to their own directory, and breaking that hierarchy is what causes the usual "white page with no styling" problem. There's also a --depth flag that controls how many levels of linked pages it will follow. Default is 1, which means it saves the current page and its direct assets. Set it to 2 and it will also grab pages linked from within that page's content. I typically leave it at 1 unless I'm archiving something small and self-contained. Going deeper introduces a lot of unnecessary bloat and slows the process significantly.

A Specific Problem I Ran Into

Last year I was archiving a client's product documentation site — roughly 40 pages with heavy reliance on a design system that served all icons as SVG sprites from a single endpoint. Save The Balloon handled the pages fine, but the SVG sprite was referenced via an absolute URL that pointed to the live CDN. Every icon was broken in the saved version. The workaround was simple once I figured it out. I used the --url-rewrite flag with a custom pattern that matched the CDN domain and redirected it to a local path. Then I manually downloaded the single SVG sprite file and placed it in the right spot. Twelve minutes total. The tool doesn't have a built-in "catch-all CDN rewrite" option, which feels like an oversight, but the regex-based flag covers most edge cases if you know what you're looking for.

What It Can't Handle

JavaScript-heavy SPAs are the main weakness. If a page loads its content through API calls after the initial render — and Save The Balloon captures the pre-render DOM — you'll get a blank shell. This isn't a bug, it's a fundamental limitation of the approach. For those sites you need a full browser automation solution instead, like Playwright or Puppeteer with a wait-for-selector strategy. Anti-bot protections are another real problem. Cloudflare, Akamai, and similar WAFs will block the headless browser on sites with aggressive detection. I've had it fail on about 15 percent of the pages I've tried to archive from certain enterprise sites. There's no reliable workaround short of using a real browser profile with cookies already set, and even then it's hit or miss. Video and audio elements embedded through third-party players — YouTube, Vimeo, SoundCloud — won't save. The tool captures the iframe embed code, not the actual media file. This is obvious in retrospect but worth stating plainly if you're counting on this for media archival work. You'd need a separate tool for that.

Command Line Examples

Basic usage is simple: save-the-balloon https://example.com/page --output ./archive This saves the page to a folder called "archive" in your current directory. It takes about 30 seconds for a typical article with a few images. A heavier page with embedded fonts and a large hero image might take two or three minutes.

For pages that require login: save-the-balloon https://intranet.company.com/docs --cookies ./cookies.txt --auth-user admin --auth-pass secret The cookie file should be in Netscape format. You can export it from your browser using an extension like "Get cookies.txt". This has saved me more than once when dealing with internal documentation sites that refuse to work without session cookies.

For batch operations across a list of URLs: cat urls.txt | save-the-balloon --batch --output ./batch-archive --concurrency 3 Running with concurrency set to 3 means it processes three URLs at once. I've found that going above 5 causes rate-limiting issues on many sites, and the disk I/O starts becoming a bottleneck on older machines. Three is the sweet spot for most setups.

Performance Reality Check

On a typical laptop with an SSD, a standard blog-style page with up to 20 assets saves in under a minute. A media-rich landing page with embedded fonts, video placeholders, and dozens of images might take three to five minutes. Pages with very large asset counts — think product catalogs with hundreds of images — are better suited to a server-grade machine or a cloud instance, otherwise you're waiting a long time and tying up your computer. Memory usage scales roughly linearly with asset count. I've seen it peak at around 400MB on a page with about 80 combined assets. Not extreme, but worth noting if you're running it alongside other tools in a pipeline.

When I'd Recommend Something Else

If you need to archive entire websites with deep navigation structures, Wget or HTTrack are still viable options, though they lack some of the modern browser rendering that Save The Balloon provides. For pure PDF conversion, the browser's built-in print-to-PDF is often more reliable than trying to save a page and then converting it separately. If your goal is long-term web preservation at scale, tools built specifically for that purpose — like the Internet Archive's wayback machine tools or Heritrix — are more appropriate. Save The Balloon fills a middle ground: quick, reliable, single-page saves that you can hand off to someone who needs to view content offline without much setup.