The Carbon Footprint of Short URLs - How to Think About CO2 from Redirects

Short URLs are a convenient tool, but behind the scenes each one triggers an additional HTTP redirect. The energy consumed by a single redirect is tiny, but as redirects are repeated around the world, that load adds up. This article sets out how to think about the CO2 that redirects generate and explores design-level strategies for reducing it.

The electricity consumed by a single web request, combining data center processing and network transmission, is thought to be only a tiny amount. When a user clicks a short URL, their browser first sends a request to the URL shortening server, then follows the redirect to the destination. Compared to a direct visit, this means at least one additional request.

The CO2 emissions from this additional request depend on the carbon intensity of the electricity used. Viewed one at a time, the amount is only tiny. But as the number of requests adds up, the total grows larger.

Bitly and other URL shortening services process clicks every day. Adding TinyURL, Rebrandly, and the built-in URL shorteners of social media platforms, the total number of redirects worldwide is thought to be large.

Accumulated at this scale, the annual CO2 emissions are unlikely to be small. This makes redirects part of the environmental question as well. Redirects are not something to dismiss as trivial.

Some URL shortening services use a CDN (Content Delivery Network). When a CDN edge server caches the redirect destination, the request is handled at a node close to the user without ever reaching the origin server.

CDNs such as CloudFront and Cloudflare can answer requests from their edge caches. Responding at the edge saves the round trip to the origin server. URL shortening services that make use of CDN caching tend to keep their environmental load lower.

The HTTP status code used for redirects also affects environmental impact. A 301 (Moved Permanently) response may be cached by the browser, and while it is cached, when the same user clicks the same short URL again, the browser redirects from its cache. During that time no server request is made, so no redirect round trip occurs.

A 302 (Found) response, on the other hand, is not cached by default. Services that want to track every click may use 302, in which case a server request is generated even for repeat visits. Assuming a repeat click rate of 20%, switching to 301 alone could reduce total request volume by roughly 15-20%.

For use cases where click analytics are unnecessary - such as sharing links in internal documents or embedding URLs in printed QR codes - choosing 301 redirects also helps reduce environmental impact.

When designing or selecting a URL shortening service, here are the key considerations for minimizing environmental impact.

First comes CDN edge caching. Minimizing requests that reach the origin server reduces energy consumption across the network. Second comes the choice between 301 and 302 based on the use case. Using 301 for links that do not require analytics lets the browser cache do its work. Third comes the power source of the data center as a selection criterion. Choosing a cloud that uses renewable energy reduces the emissions from the electricity behind redirects.

There is a growing selection of titles covering data center energy efficiency and sustainable infrastructure design.

The CO2 emissions from a single redirect are only tiny. But accumulated over a year, the total emissions are not small. Leveraging CDN caching, adopting 301 redirects where appropriate, and choosing infrastructure powered by renewable energy - taken together, these design decisions can be expected to lower the environmental footprint of URL shortening. Balancing convenience and sustainability is also a design challenge for URL shortening services.