Carbon Shrinker

🖥️ Drag & drop (the Compress tab)

This is the simplest path, and the most private one: your file never leaves your device. Compression happens entirely inside your own browser, using your device's own processing power — nothing is uploaded to us, not even temporarily. Once it's done, the smaller file saves straight to your device, as a new file sitting alongside the original.

For video specifically, there are two different methods under the hood, chosen automatically based on file size. Anything under 1GB uses a fast method that can compress many times faster than the video's own length. 1GB and over uses a slower method instead — roughly as long as the video itself — because the fast method has to hold the whole file in your browser's memory at once, which risks crashing the tab on a very large file. The slower method never does that, so it's the safer choice once a file gets that big. You'll see a note on the file itself when this applies.

🖼️ Why do my PNGs come back as WebP?

Every image we compress — JPEG, PNG, or otherwise — comes back as a WebP file. That's a deliberate choice: WebP reliably produces a smaller file than the same image saved as a PNG or JPEG at an equivalent visual quality, which is the whole point of compressing it in the first place.

A common assumption is that this breaks transparency — PNG's signature feature for logos, icons, and graphics with a see-through background. It doesn't: WebP fully supports transparency, the same way PNG does, and it's preserved correctly through the conversion. What does change is the file extension itself — if something you're uploading it to specifically requires a .png file by name, you may need to rename it back or convert it again on the other end.

As with every file type here, the same promise applies: if converting an image wouldn't actually make it smaller, we hand back the original untouched rather than a same-size (or bigger) WebP.

☁️ Cloud Connect (Google Drive / OneDrive)

This works differently, because it has to reach into your actual cloud storage rather than a file you've opened in a browser tab. Here's exactly what happens to every file, one at a time:

1. List — we ask Google Drive or OneDrive for every file in the folder you connected.
2. Download — that file's contents get pulled onto our server, temporarily, purely as working space to process it.
3. Compress — our compression engine shrinks it.
4. Compare — we check whether the compressed version is actually smaller.

5. Clean up — once the whole run finishes, every temporary copy on our server — original and compressed alike — is deleted. Nothing from your files is stored here afterward.

A file's original does briefly pass through our server during that process — that's unavoidable, since we can't measure or compress something we can't see. But it's never kept, and it's only ever written back to your Drive/OneDrive if the result is a genuine improvement.

⚡ Cloud Auto-Compression (Microsoft 365)

Different from the OneDrive Cloud Connect above, which connects as one signed-in person and only checks a folder when you ask it to. This one is genuinely real-time: an admin approves it once for the whole organisation, and from then on Microsoft itself tells us the instant a file changes in the connected SharePoint or OneDrive library — no polling, no clicking "Run compression."

It's built to be set and forget. Microsoft's own subscription to those change notifications technically expires every few days, but we check every hour and renew it a full day ahead of time, automatically, for as long as the connection stays approved — nobody needs to re-approve anything. If a renewal ever genuinely failed, it emails an alert rather than silently going quiet.

One real limit worth knowing: it watches one specific library at a time — the one an admin named when connecting it. A second SharePoint site or library needs its own separate "Connect" step, same as adding another Cloud Connect folder. And naturally, if the Microsoft permission is revoked, or the connection is removed here, it stops.

🌍 Where the CO2e-saved figure comes from

We use the Sustainable Web Design Model v4 (SWD v4) — the same methodology behind Web Zero's own Tier 2 website carbon reports, and one of the most widely-used carbon models on the web (via CO2.js, the Green Web Foundation's reference implementation). It converts a number of gigabytes into real gCO2e, based on published figures for how much electricity it genuinely takes, on average, to move and process data across three segments: the data centre it starts in, the network it travels across, and the device it ends up on — each split further into the electricity actually running that equipment and a share of the energy embodied in manufacturing it in the first place.

Worth being upfront about: these figures are genuine global averages of energy per gigabyte moved through the internet and device ecosystem as a whole — they were never built specifically around web browsing or any one transmission protocol, so the same figure applies whether that gigabyte was a webpage loading or a file being sent. We calculate it as if the bytes you save are sent or downloaded once — deliberately not applying the extra discount a repeat website visitor gets from browser caching, since a compressed file being emailed or uploaded doesn't get cached the same way. That's a conservative choice: it doesn't account for a file being downloaded or viewed many times, which would make the real saving even bigger than the figure shown.

💧 Where the water-saved figure comes from

Every gigabyte of data sitting in the cloud, or moving across the internet, takes real electricity to run — and data centres use real water to keep that electricity turning into heat they can get rid of, mostly through evaporative cooling towers. There's a real, published industry metric for this: Water Usage Effectiveness (WUE) — litres of water per kilowatt-hour of computing power used.

We start from the same "how much electricity does this file take to store and move" figure already behind the CO2e number above — but only the data-centre share of it, since that's the only part of the journey where cooling water is actually used (not the network in between, and not your own device). We then multiply that by 0.25 litres per kilowatt-hour — the average of what Microsoft and Amazon Web Services have themselves published for their own data centres in 2025 (0.30 and 0.19 L/kWh respectively). We use their figures specifically because Cloud Connect's own two providers, OneDrive and Google Drive, run on exactly this class of large, modern data centre — Microsoft's and Google's own.

Worth knowing honestly: this varies a lot by provider and location. Google's own data centres are estimated at roughly four times as much water per kilowatt-hour, mostly down to a different cooling design. So treat the litres figure as a genuine, sourced, real-world estimate — not an exact receipt for any one specific file.

💷 Where the £ saved figures come from

This one genuinely depends on where your files live — Google Drive, Microsoft OneDrive/SharePoint, Dropbox, Box, and a plain browser download aren't priced the same way, so we don't use one flat number for all of them.

Google Drive, OneDrive, Dropbox, and Box are subscription products — you pay a flat monthly fee per person that already includes a chunk of storage, not a per-gigabyte bill. So instead of a metered price, we use each one's real, published plan price divided by the storage it includes — e.g. Microsoft 365 Business Standard is $14/person/month for 1TB, working out to roughly $0.0137 per GB per month of that allowance. Google Workspace and Dropbox Business work out cheaper still per GB, since they bundle more storage into a similar price. Think of this as "what a gigabyte of your plan's headroom is really worth" — genuine and sourced, but an estimate of value, not a literal invoice line.

Box is a genuine exception worth flagging honestly: its entry-level plan (Business Starter) works out to a real per-GB rate the same way, but Box's higher tiers (Business and above) are unlimited storage, not just a bigger allowance. For a company on one of those, there's no real "£ saved on storage" the way there is for a capped plan — compressing a file never delays or avoids a plan upgrade if storage was never the constraint to begin with. We use the entry-tier rate as a conservative estimate for every Box-sourced job, which may overstate the real saving for a larger Box customer.

None of those four charge extra to actually download or open your own files, either — it's just part of the subscription. So for anything compressed via Google Drive, OneDrive, Dropbox, or Box, the "saved on data transfer" figure is honestly £0 — not a rounding error, there's genuinely no separate transfer cost being saved there.

Files compressed straight in your browser (destination unknown to us) or through the Cloud-Native/AWS route (which really does run on metered AWS infrastructure) still use real AWS S3 Standard rates for both figures, same as before — that's the one case here that's genuinely billed per gigabyte, transfer included.

🎬 Video

Both the Compress tab and Cloud Connect now handle the same wide range of formats: .mp4, .mkv, .avi, .mov, .webm, .wmv, .flv, .m4v — all normalized to standard MP4 on the way out, since a mix of source formats coming back as one consistent, universally-playable format is more useful than preserving whatever container each one started in.

The two paths still work completely differently under the hood (see How It Works) — the Compress tab never uploads your file anywhere, Cloud Connect runs on our server — but format support is no longer the thing that differs between them.

One real speed caveat on the Compress tab: a video 1GB or larger automatically switches to a slower compression method — taking roughly as long as the video itself, rather than a fraction of that — to avoid a real risk of crashing the browser tab on a file that large. It still works, just not as fast. See How It Works above for why.

🖼️ Images

Doesn't work (either path): HEIC/HEIF — the default photo format on iPhone since iOS 11. This is a real, common gap and actively being worked on. RAW camera formats (.cr2, .nef, .arw, etc.) and SVG (a completely different, non-pixel format) are also not covered.

Everything else — JPEG, PNG, WebP, GIF, BMP — works normally on both paths.

📄 Documents

Doesn't work: the old, pre-2007 Microsoft formats — .doc, .xls, .ppt. These use a completely different, non-zip file structure from their modern replacements.

.docx, .xlsx, .pptx, .epub, .odt, .ods, and .odp all work normally.

🎵 Audio

Doesn't work: .wma (Windows Media Audio).

.mp3, .wav, .m4a, .aac, .ogg, .flac, .aiff, and .aif all work normally.

🏢 Who we are

Carbon Shrinker is a product of Web Zero . For anything in this notice, or to exercise any of the rights below, contact us via the Contact us form, or write to us directly.

📋 What we collect, and why

Account details: your email address and a password (stored as a one-way bcrypt hash — we never see or store your actual password). Your company is worked out automatically from your email domain, so colleagues at the same organisation share one team.

Session tokens: a random, meaningless-on-its-own token that keeps you logged in, held in your browser's local storage — not a tracking cookie, and not shared with anyone.

Compression activity: when you compress a file using the Compress tab or the desktop app, we log only the file type and the before/after size, so your dashboard can show real savings. The file itself is never uploaded to us for this — compression runs entirely on your own device. See Data & Security for more.

Cloud Connect / Cloud Auto-Compression: if your company chooses to connect its own Google Drive, OneDrive, Dropbox, Box, or SharePoint account, files from the one folder you connect are downloaded to our server, compressed, written back, and the temporary copy is deleted immediately — this is the one part of the product where file content passes through our servers at all, and only for companies who've explicitly opted into this specific paid feature.

Payment: card details are entered directly into Stripe's own secure checkout page. We never see or store your card number.

Support messages: anything you send us via the Contact form or by email, so we can reply to you.

⚖️ Our legal basis for processing this

Mostly contract — we need this data to actually provide the service you've signed up for. Some (like keeping basic technical logs to fix bugs and keep the service secure) is legitimate interest. We don't currently send marketing emails, so we don't rely on marketing consent for anything.

🔗 Who we share data with

We use a small number of specialist providers to actually run the service, each only for what they're named for — we don't sell or trade your data to anyone, ever:

Stripe — payment processing. Resend — sending the emails the service itself sends you (verification, password reset, activity summaries). Sentry — technical error monitoring, configured not to automatically collect things like your IP address. Zoho — our own internal customer records. Railway — the servers everything runs on. And, only if your company connects them, Google, Microsoft, Dropbox, or Box — solely to read and write files in the one folder you've chosen to connect.

🌍 Where your data is stored

Our servers run on Railway's infrastructure in the United States. This means your personal data is transferred outside the UK/EEA . We only work with providers who take data protection seriously, and we're happy to answer questions about this directly if you ask.

🗓️ How long we keep it

For as long as your account is active. We don't currently auto-delete historical records (like past compression activity or reports) after a fixed period, since companies often want to see long-term trends. You can ask us to delete your account and associated data at any time via the Contact form — we'll action this as quickly as we reasonably can.

🍪 Cookies & local storage

We don't currently use tracking cookies or any third-party analytics on this site. The only thing we store in your browser is the login session token described above, which is strictly necessary for the service to work at all. If that ever changes (for example, if we add website analytics in future), we'll update this notice and ask for your consent first wherever that's legally required.

🎯 Our commitment

We want Carbon Shrinker to be usable by as many people as possible, including people using a screen reader, keyboard-only navigation, browser zoom, or other assistive technology. This is a genuine, ongoing effort, not a one-off checkbox.

✅ Where we are today

The site is built with standard HTML form controls, buttons, and labelled inputs, which generally work reasonably well with keyboard navigation and screen readers out of the box. Error and success messages are shown as plain, readable text rather than colour alone. That said, we haven't yet put this through a formal accessibility audit against the WCAG standard, so we're not making a formal conformance claim here — we'd rather tell you honestly where we are than overstate it.

⚠️ Known limitations

Payment happens on Stripe's own checkout page, which follows Stripe's own accessibility standards rather than ours directly. The desktop app (Mac/Windows) hasn't specifically been tested with screen readers. Some data visualisations on the dashboard (charts) don't yet have a full text-based alternative.

🔒 The core promise

For the free Compress tab and the desktop app, your files never leave your own device. Compression runs entirely in your browser (or, for the desktop app, locally on your computer) — there is no upload step to skip, because there's nothing to upload. This isn't a policy choice we could quietly change; it's how the underlying technology (WebCodecs, running in your browser) actually works.

🔐 How your account is protected

Passwords are hashed with bcrypt before storage — a one-way process, so even we can't see your actual password. All traffic to and from Carbon Shrinker is encrypted (HTTPS). Login sessions use a random, opaque token rather than anything derived from or revealing your password.

☁️ Cloud Connect's server-side handling

When Cloud Connect or Cloud Auto-Compression processes a file from your company's connected cloud storage, it's downloaded to a temporary location on our server, compressed, written back to your own cloud storage, and the temporary copy is deleted immediately once that run finishes — never kept, never backed up, never used for anything beyond that one compression.

💳 Payment security

Card payments are handled entirely by Stripe's own hosted checkout — a PCI-compliant payment processor used by a huge range of real businesses. Your card details are never entered into, or stored by, any Carbon Shrinker server.

🌍 Where things run

Our servers and databases run on Railway's cloud infrastructure, currently hosted in the United States. See our Privacy Notice for what this means for international data transfers.