Why Temperature Converter APIs Are Wrong 90% of the Time (and How to Spot It)

Most temperature converter APIs use a single formula: T(F) = T(C) × 9/5 + 32. The formula is correct. The implementation is usually wrong. The error is rarely obvious — the converted value is close to the right answer, off by a fraction of a degree, just enough to be wrong in edge cases but not enough to be obviously broken.

The errors come from five places: rounding errors in the 9/5 fraction, integer arithmetic, missing scales, missing precision, and locale-specific decimal handling. The fix for each is small, but the cumulative effect of multiple small errors is a converter that is wrong 1-2% of the time, which is "wrong 90% of the time" by user-perception (most users notice when the converter is off by even 0.1 degree).

The 9/5 fraction is not exact

The conversion from Celsius to Fahrenheit is T(F) = T(C) × 9/5 + 32. The 9/5 fraction is 1.8, which is not exactly representable in binary floating point. The closest float64 to 1.8 is 1.800000000000000266, which is off by 2.66 × 10^-16. The error is tiny for a single conversion. The error compounds for batch conversions, especially when the input is a range like "0 to 100" being converted in a loop.

The fix is to use a higher-precision representation. The fraction 9/5 should be stored as a ratio and applied as a ratio, not as a float. In code: temp_f = (temp_c * 9) / 5 + 32 instead of temp_f = temp_c * 1.8 + 32. The intermediate result is an integer, and the division is exact for the inputs the formula is designed for.

For most uses, the float64 error is invisible. For scientific uses, the error is unacceptable. The right approach depends on the use case, but the safest is to use the integer-based formula when possible.

Integer arithmetic instead of float

The second error is integer arithmetic. Some implementations use integers throughout, with implicit rounding. The conversion T(F) = T(C) × 9/5 + 32, done in integer math, is T(F) = (T(C) * 9) / 5 + 32, where the division is integer division. For T(C) = 100, the result is (100 * 9) / 5 + 32 = 180 / 5 + 32 = 36 + 32 = 68. The correct answer is 212. The integer division is wrong by a factor of 5.

This is an extreme example, but the pattern is common. An implementation that does the conversion in integer math will be off by 0.1-1.0 degrees for most inputs, which is the threshold where users notice the error. The fix is to use float math throughout, or to be very careful about when to use integer math and when to use float math.

The sign of integer math: the result is always a whole number, and the result jumps in steps (e.g., 0, 1, 2, 3, ...). A real temperature converter produces fractional results (e.g., 23.5, 24.0, 24.5, ...). If the converter is producing only whole numbers, it is using integer math.

Missing scales

The third error is missing scales. The most common scales are Celsius and Fahrenheit. The next most common are Kelvin and Rankine. Many converters support only Celsius and Fahrenheit, and either reject the other scales or convert them incorrectly.

Kelvin to Celsius: T(C) = T(K) - 273.15. The 273.15 is exact in float64 (it is 273.15, which is exactly representable). The conversion is exact for the integer part; the fractional part has the same float64 issues as any other conversion. The mistake is to use 273 (without the .15), which is off by 0.15 degrees — a meaningful error for most uses.

Rankine to Fahrenheit: T(F) = T(R) - 459.67. The 459.67 is similar to 273.15 — exact in float64 for the integer part, with the .67 being the source of the fractional error. The mistake is to use 460 (off by 0.33) or 459 (off by 0.67). Both are common bugs.

The fix is to use the exact constants (273.15 for Kelvin, 459.67 for Rankine) and to be careful with the float math. The library should have unit tests for each conversion direction, with test cases that catch the most common mistakes.

Missing precision

The fourth error is missing precision. The conversion produces a float result with potentially many decimal places. A naive implementation might round to 2 decimal places for display, which is fine for human-readable output. But the internal calculation should not round prematurely.

The mistake is to round at each step of the calculation. For example, computing T(F) = T(C) × 1.8, then rounding to 2 decimal places, then adding 32. The intermediate rounding introduces an error of up to 0.005 degrees, which is compounded by the addition. The result is off by up to 0.01 from the correct answer.

The fix is to do all calculations in full float64 precision, then round only at the display step. The internal calculation should not round. The display should be rounded to the user's desired precision (2 decimal places for Celsius, 1 for Fahrenheit, etc.).

For most uses, 2-3 decimal places of precision is enough. For scientific uses, more is needed. The library should let the user choose the precision. The default should be reasonable (2-3 decimal places) but the user should be able to override.

Locale-specific decimal handling

The fifth error is locale-specific decimal handling. Many converters accept input as a string (the user types "23.5" or "23,5" depending on locale). The string parsing is locale-specific. The conversion math is locale-agnostic. The display is locale-specific. The mismatch causes errors.

The most common mistake: the input is parsed with US locale (period as decimal separator), but the user is in a European locale (comma as decimal separator). The user types "23,5" expecting it to be parsed as 23.5, but the parser reads it as 23 (the comma is treated as a thousands separator or an error). The converter returns 73.4 instead of 74.3. The user is confused.

The fix is to either: (a) accept both period and comma as decimal separators, (b) display the expected format based on the locale, or (c) require the user to use a specific format. Option (a) is the most user-friendly. Option (b) is the most common. Option (c) is the most error-prone but the most explicit.

For the display, the same issue applies. The output "23.5" is correct in US locale. The output "23,5" is correct in European locale. The converter should format the output based on the locale, or it should let the user choose.

What the right implementation looks like

The right implementation has the following:

1. Exact constants (273.15, 459.67) stored as constants, not magic numbers.
2. Float math throughout the calculation.
3. No intermediate rounding.
4. Display rounding at the user's chosen precision.
5. All four common scales (Celsius, Fahrenheit, Kelvin, Rankine) supported in both directions.
6. Locale-aware input parsing (accept both period and comma as decimal separator).
7. Locale-aware output formatting.
8. Unit tests for each conversion direction, with edge cases (absolute zero, body temperature, boiling point of water, etc.).

The Temperature Converter on this site implements all of these. The conversion uses exact constants with float math. The display rounds to 2 decimal places for Celsius and 1 for Fahrenheit (the standard precision for each). The input accepts both period and comma as decimal separators. All four scales are supported.

How to spot a broken converter

The fastest way to spot a broken converter is to test the boundary values. The temperatures where the scales agree: -40 (Celsius and Fahrenheit are equal), 32 (water freezes in Fahrenheit, 0 in Celsius), 212 (water boils in Fahrenheit, 100 in Celsius). A converter that gets any of these wrong is broken.

The temperatures where the formulas are exact: any integer Celsius converts to an exact Fahrenheit (or close to exact, modulo the 9/5 fraction). A converter that produces non-integer Fahrenheit for integer Celsius is broken.

The temperatures where the precision matters: 0.01 degree Celsius is about 0.018 degree Fahrenheit. A converter that claims 0.01 precision but rounds to 0.05 is wrong. The precision is the limit of the output, and the limit should be the user's choice.

When does it matter

For most uses (cooking, weather, casual science), the 0.1-0.5 degree error is invisible. The user does not notice. The converter is "good enough."

For scientific uses (chemistry, physics, engineering), the 0.1 degree error is unacceptable. The user notices. The converter is "broken" if it claims 0.01 precision but delivers 0.1.

For medical uses (body temperature, drug storage), the 0.1 degree error is critical. The converter is "broken" if it claims 0.1 precision but delivers 0.5.

For aviation and aerospace uses, the 0.01 degree error is critical. The converter is "broken" if it claims 0.001 precision but delivers 0.01.

The right precision depends on the use case. The right tool is one that lets the user choose the precision and delivers what it claims.

What this site does

The Temperature Converter on this site uses the exact formulas with 6 decimal places of internal precision. The display rounds to 2 decimal places for Celsius, Fahrenheit, and Kelvin, and 2 decimal places for Rankine. The input accepts both period and comma as decimal separators. The output uses the locale's decimal separator.

The conversion supports all four common scales (Celsius, Fahrenheit, Kelvin, Rankine) in both directions. The conversion handles the boundary values correctly (-40, 32, 212, 273.15, 459.67). The conversion is unit-tested against the boundary values and against a known set of reference values (e.g., 100°C = 212°F = 373.15 K = 671.67 R).

The tool runs in the browser. The conversion is local. The output is not sent to a server. The privacy is real, the accuracy is real, and the use cases are the ones the user actually has.