Building a BMI Calculator That Doesn’t Suck

I needed a BMI calculator for a project. Not a React app with a 5MB bundle, not a server-rendered form that phones home to three analytics services. Just a single HTML file that works offline, respects privacy, and doesn’t make users wait for a loading spinner. The math is trivial. The rest? Not so much.

The Unit Conversion Nightmare

Metric users type one number for height. Imperial users think in feet and inches. Asking them to convert 5’6” to 5.5 and hope for the best is a recipe for frustration. The fix was straightforward: separate inputs for feet and inches, then convert everything to metric internally before doing the calculation. This avoids the classic bug where the display updates but the math doesn’t.

The conversion itself is simple. One inch equals 0.0254 meters, one pound equals 0.453592 kilograms. The real work is making sure the UI reflects how people actually measure themselves, not how computers prefer to store numbers.

Visualizing BMI Without Lying

A progress bar is misleading. BMI categories aren’t linear. The jump from 18.4 to 18.5 is far more significant than the jump from 22 to 23, even though the numerical difference is the same. A segmented gauge works better. Each category gets a width proportional to its actual range, so users see that “overweight” covers a wider span than “normal.” It’s honest, and it’s clearer.

AI Helped, Then It Didn’t

I used AI for parts of this project. It handled boilerplate well: generating a clean i18n structure, setting up a responsive layout. Then it hallucinated. Switching from metric to imperial preserved the value but not the unit, turning 170cm into 170 feet. The gauge marker positioning relied on a magic number that broke in real-world use.

• AI excels at structure and repetitive tasks.

• It fails at semantic understanding, especially with units.

• Always test edge cases manually.

Privacy as a Feature

Keeping everything client-side wasn’t just about privacy. It was about performance. The tool loads in under 100KB and works instantly, even on slow connections. No API calls, no analytics, no tracking. For a utility, that’s a feature, not a limitation. The trade-off? No usage data, no A/B testing. For this kind of tool, that’s a fair price.

Input Validation: The Unsexy Necessity

Enter zero for height or a negative number for weight, and the formula breaks. The result is NaN or Infinity, and your gauge points to nowhere. The fix is basic validation: reject zero or negative values, and set reasonable upper limits. The tricky part is deciding what’s reasonable. 300cm is tall but possible. 500kg is extreme but exists. I chose generous limits that catch typos without being judgmental.

Design Choices That Actually Matter

Dark mode wasn’t optional. CSS custom properties and prefers-color-scheme made it easy. Responsive design meant more than scaling down. On mobile, the two-column input grid stacks into one, and the gauge labels stay readable at 320px. Font choice mattered too. A monospace font for numbers prevents the jittery effect you get when digits shift in a proportional font.

The i18n Gotcha

Translating labels isn’t enough. The format of the numbers changes too. In English, 5’10” is clear. In other languages, the notation is different. The solution was separating translation logic from formatting logic. This way, the math stays consistent, and the display adapts to the user’s language and culture.

What I’d Change Next Time

• Better error handling for extreme values. The current version catches obvious typos but could be more graceful.

• More granular BMI categories. The WHO standard has seven, but I only implemented four. For a clinical tool, you’d want the full range.

• History tracking. Storing previous calculations in localStorage would help users track progress over time.

The Big Lesson

Even simple tools have layers of complexity. The BMI formula fits in three lines of code. Making it work across cultures, devices, and user preferences takes real engineering. The best architecture is often the simplest: no build step, no dependencies, no server. Just a well-crafted HTML file that does one thing well.

If you’re building something similar, start with the math. Obsess over the UX. And never trust AI to handle unit conversions without testing every edge case yourself.