Build Report · E-Commerce / Tooling

Dynamic Carbonation Calculator
Replacing static charts with a usable tool

Most carbonation charts are technically correct and practically useless. This is the story of replacing them with a browser-based calculator that adapts to real-world conditions — built to run inside Magento with zero dependencies.

Author Calvin Graham Stack Vanilla JS · HTML · CSS Domain E-Commerce / Homebrew Live gwkent.com/carbcalc →

Overview

Carbonation targets are expressed in volumes of CO₂ or grams per liter. To hit a target, brewers need to know the right pressure to apply at a given temperature. For decades, the answer has been a laminated chart on the wall of a homebrew shop — or a PDF someone found on a forum in 2009.

The problem isn't the math. The math is settled. The problem is the delivery: static charts bake in assumptions that don't hold for most users. The result is guesswork dressed up as precision.

This tool was built for G.W. Kent, a brewing and winemaking supplier, to embed directly on product pages within their Magento storefront. The goal was to reduce support friction and give customers a better answer at the moment they need it.

The Problem

Standard carbonation charts assume a narrow set of conditions. Outside those conditions, the chart quietly gives you the wrong number. Most real users are outside them.

What Charts Assume

What a static chart assumes

  • Sea level atmospheric pressure
  • Standard ambient conditions
  • No alcohol content (water-based solution)
  • One target unit (volumes or g/L, not both)

What real-world users have

  • Variable elevation (Colorado is 5,000+ ft)
  • Different cellar and keezer temps
  • Beers from 4% to 12%+ ABV
  • Mixed unit preferences

The Real-World Gap

At altitude, atmospheric pressure is lower. That changes the equilibrium point for dissolved CO₂. A brewer in Denver following a sea-level chart will consistently overcarbonate. A higher-ABV beer has a different CO₂ solubility profile than water, which shifts the pressure target further.

These aren't edge cases. They're the norm. The fix wasn't a new formula. It was building something that actually used the right variables.

The chart isn't wrong. The context is. A sea-level chart used at 5,280 ft can put you 2–4 PSI off target, enough to noticeably over- or under-carbonate a finished beer.

What I Built

A browser-based carbonation calculator that takes three real-world inputs and returns one actionable output: the PSI to set on your regulator.

Parameter Type Why It Matters
Temperature Input CO₂ solubility is highly temperature-dependent; a few degrees changes the PSI target meaningfully
Elevation Input Atmospheric pressure decreases with altitude, shifting the equilibrium pressure required
ABV Input Alcohol reduces CO₂ solubility vs. water; ignored by every standard chart
Required PSI Output Regulator pressure to hit the target carbonation level
Unit toggle (vols / g/L) Output Users can express the target in whichever unit their recipe uses

No backend. No API calls. The calculation runs entirely in the browser, which means it loads instantly and can be dropped into any Magento CMS block or product description without touching the app layer.

Try it live at gwkent.com/carbcalc →

Technical Approach

The constraints were tight: no app layer, no build step, no external dependencies, and it had to be mobile-friendly enough to use in a brewery. The solution is a single self-contained HTML file.

The Core Formula

CO₂ equilibrium pressure is derived from Henry's Law, adjusted for temperature, elevation, and ABV. The altitude correction converts elevation to atmospheric pressure using the barometric formula, then folds that into the gauge pressure calculation.

javascript
// Atmospheric pressure drops ~0.5 PSI per 1,000 ft of elevation
function atmPressure(elevationFt) {
  const elevationM = elevationFt * 0.3048;
  return 14.696 * Math.pow(1 - (2.25577e-5 * elevationM), 5.25588);
}

// Henry's Law constant for CO₂ — temperature adjusted (°F input)
function henryConstant(tempF) {
  const tempC = (tempF - 32) * 5 / 9;
  return Math.exp(-10.73797 + (2617.25 / (tempC + 273.15)));
}

// Required gauge PSI given target volumes, temp, elevation, and ABV
function calcPSI(volumes, tempF, elevFt, abv) {
  const atm    = atmPressure(elevFt);
  const kH     = henryConstant(tempF);
  const abvAdj = 1 - (abv * 0.012); // alcohol reduces CO₂ solubility
  const absP   = (volumes / (kH * abvAdj));
  return (absP - atm).toFixed(1); // gauge pressure
}

Deployment

Magento's CMS allows raw HTML blocks on product and content pages. Because the calculator is a single file with no external dependencies, embedding it is a paste operation: no module, no extension, no deployment pipeline.

  1. Author the calculator as a standalone HTML file with inline styles and script.
  2. Paste the markup into a Magento CMS block via the admin panel.
  3. Assign the block to the relevant product page or category landing page.
  4. The tool renders immediately, with no CDN, runtime, or API quota to worry about.
Zero-dependency, client-side tools like this have an underappreciated upside in e-commerce: they never go down independently of the storefront. No third-party outage, no rate limit, no cold start.

Outcome

The calculator replaced a static chart that had been linked from product pages for years. The shift from reference to decision tool changed how customers interacted with the information.

What improved

  • More accurate carbonation setups for customers at altitude
  • Fewer support questions about PSI targets
  • Higher-ABV beers dialed in correctly on the first attempt
  • Unit flexibility — volumes and g/L in one place
  • Embeds anywhere Magento renders HTML

What stayed the same

  • The underlying chemistry — no new math required
  • Deployment complexity — still zero
  • Page load impact — no measurable change

The Broader Point

A lot of "tools" in e-commerce are really just documents with interactive chrome bolted on. This one is the opposite: the interaction is the product. The moment a customer in Denver enters their elevation and gets a different number than the chart gave them, the tool has done its job.

Better delivery of existing knowledge is a legitimate product decision. It doesn't require new data, new infrastructure, or a new team. It requires understanding where the gap between information and action actually is.