Deceptively good beginner project: trivial to start, and the details — precision, chained conversions, awkward units — teach you a lot about handling numbers carefully.

1. Convert through a base unit

Don't write a conversion for every pair. Define one base unit per category and convert through it: metres for length, grams for mass, and so on. Adding a new unit becomes one number rather than twenty.

unit-converter.txt
Build a unit converter, one page, no server.

- Categories: length, mass, volume, temperature, area, speed, data.
- Convert through a base unit per category, with factors in one data
  object so adding a unit is a one-line change.
- Temperature needs offsets, not just factors — handle it separately
  and say why.
- Live conversion as I type, both directions.
- Sensible precision: don't show 2.9999999999 or 15 decimal places.
  Say how you decided how many to show.

Handle: empty input, negative values where they're meaningless (a
negative length), and very large or very small numbers.

2. Temperature breaks the pattern

Every other conversion is multiplication. Temperature has an offset — Celsius to Fahrenheit isn't a scale factor. It's the case that breaks a naive design, and it's worth structuring for from the start.

3. Precision is the real problem

Floating point produces 0.30000000000000004 and users notice. Round for display based on the magnitude of the result — a value near zero needs more decimal places than one in the thousands.

Never round the stored value; round only what's shown. Otherwise chained conversions accumulate error.

4. Make it fast to use

Remember the last-used category and units. Keyboard-first: type a number, tab to the unit, done. A URL that encodes the conversion so results are shareable.

Include the units people actually search for, including the awkward ones — stones, US versus imperial gallons, nautical miles. That's what makes someone pick your converter over the one already in their search bar.