Temperature Conversion Formulas: Celsius, Fahrenheit, Kelvin

You ship a weather dashboard on Monday. By Wednesday a user in Toronto files a bug: the app shows the outside temperature as 284. The OpenWeatherMap endpoint returned Kelvin (the default), your UI expected Celsius, and nothing in between cared enough to check. One missing subtraction, one broken screenshot on Twitter.

If you just need the two formulas and want to move on:

Celsius to Fahrenheit formula: °F = °C × 9/5 + 32
Fahrenheit to Celsius formula: °C = (°F − 32) × 5/9
Celsius to Kelvin: K = °C + 273.15

Those three cover roughly 90% of what developers actually need. The rest of this guide is the other 10%: where 9/5 comes from, why Kelvin is never negative, how to make your type system reject celsiusToFahrenheit(kelvinValue) at compile time, and how to stop shipping the Toronto bug. You can also skip the reading entirely and use our temperature converter when you just need a number now. For non-temperature units, see the broader unit conversion complete guide.

Why Temperature Is Different from Other Unit Conversions

Most unit conversions are trivially linear through zero. A metre is 3.28084 feet, full stop. Double the metres, double the feet. Zero metres is zero feet. You can build a conversion library with a single multiplicative constant per pair and never think about it again.

Temperature breaks this model: its scales do not share a zero point. Celsius anchors its zero at water’s freezing point. Fahrenheit anchors its zero at a 1724-era brine mixture. Kelvin anchors its zero at the theoretical floor of thermodynamics. To go between any two, you need both a scaling factor and an offset — temperature is an affine transformation, not a linear one.

This has a dangerous consequence: temperature values are not additive the way length or mass values are. 20°C + 20°C is not 40°C in any physical sense. You cannot “add two rooms together” and get a warmer room. You can add a temperature difference to a temperature, because differences are linear. That distinction is what tripped up the 2006 Medeva vaccine incident in the UK, where a pharmaceutical cold-chain logger confused an absolute reading with a delta and tagged thousands of doses as out-of-spec. Intensive quantities like temperature need this mental guardrail: numbers that share a unit do not automatically share the algebra.

The Four Temperature Scales Explained

Only two scales matter for day-to-day code (Celsius, Fahrenheit), a third matters for anything scientific (Kelvin), and the fourth shows up in exactly one place: US thermodynamics textbooks and the HVAC codebases that still reference them.

Celsius (°C)

Anders Celsius published his scale in 1742, originally with 0° at boiling and 100° at freezing — inverted from what we use now. The modern orientation, with 0°C at the freezing point of water and 100°C at its boiling point under one standard atmosphere, came shortly after his death. Today it is the SI-derived unit for everyday temperature and the default scale in every country except the United States, the Bahamas, Belize, the Cayman Islands, and Liberia.

The 2019 SI redefinition tied Celsius rigorously to Kelvin: 0°C is now defined as exactly 273.15 K. The freezing point of water, once the definition, is now a measured consequence (it lands on 0°C to within parts per million but is no longer the anchor).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit proposed his scale in 1724. He chose 0°F as the freezing point of a specific brine mixture — the coldest temperature he could reliably reproduce in a Danzig winter — and 96°F as body temperature. Later recalibration against the freezing and boiling points of pure water pushed body temperature to 98.6°F and placed freezing at 32°F and boiling at 212°F, a 180-degree span.

Fahrenheit survives in the United States for weather, cooking, and medical use. The 180-degree span between freezing and boiling (vs. 100 in Celsius) is sometimes defended as offering “finer resolution for ambient temperatures” — a marginal claim, but one that explains why American thermostats are marked in 1°F steps while European ones use 0.5°C steps.

Kelvin (K)

William Thomson, Lord Kelvin, proposed an absolute scale in 1848. The modern Kelvin is the SI base unit of temperature. The 2019 SI redefinition ties the kelvin to the Boltzmann constant k_B = 1.380649 × 10⁻²³ J/K exactly, making it a defined rather than measured quantity.

Kelvin has three quirks developers should know:

No degree symbol. Write 300 K, not 300°K. This has been the SI convention since 1967.
Starts at absolute zero. 0 K = −273.15°C. You should never see a negative Kelvin value in valid data; treat one as an input error.
Same degree size as Celsius. A change of 1 K equals a change of 1°C. Temperature differences are interchangeable between the two; only absolute values differ by the 273.15 offset.

Kelvin is the right choice any time you multiply or divide temperatures — thermal radiation (T⁴), ideal gas law, blackbody physics. Division by a negative or near-zero Celsius value blows up physics you want to keep finite.

Rankine (°R)

William Rankine proposed this scale in 1859 as the Fahrenheit equivalent of Kelvin: an absolute scale, zero at absolute zero, but with Fahrenheit-sized degrees. 0°R = −459.67°F. 491.67°R = 0°C.

You will rarely encounter Rankine outside US thermodynamic engineering — HVAC calculations, petroleum refining, rocket engine combustion analysis — where the math needs an absolute scale but the input data arrives in Fahrenheit. Converting is mechanical: °R = °F + 459.67, or equivalently °R = K × 9/5. Most modern engineering software can stay in Kelvin internally and convert only for display, which is what I recommend when you have the choice.

Temperature Conversion Formulas (All Six Directions)

Six directions, four scales, six formulas. In practice you memorise the Celsius-centred ones and compose the rest.

Celsius to Fahrenheit and Back

°F = °C × 9/5 + 32
°C = (°F − 32) × 5/9

The 9/5 factor is the ratio of the two scales’ spans between the same two physical landmarks. From freezing to boiling, Fahrenheit covers 180 degrees (32 to 212); Celsius covers 100 (0 to 100). 180 / 100 = 9/5 = 1.8. The + 32 is the offset needed to align freezing-point zeros, because Fahrenheit’s zero sits 32°F below Celsius’s zero.

Worked example: °F = 25 × 9/5 + 32 = 45 + 32 = 77°F.

Celsius to Kelvin and Back

K = °C + 273.15
°C = K − 273.15

No scaling, only an offset. 273.15 is the numerical distance from Celsius’s zero (water’s freezing point) down to absolute zero, measured in Celsius degrees. Since Kelvin and Celsius share the same degree size, there is no multiplier.

Fahrenheit to Kelvin and Back

K = (°F − 32) × 5/9 + 273.15
°F = (K − 273.15) × 9/5 + 32

There is no shorter form — both a scale change and an offset change are needed. In code, it is cleaner to route through Celsius: k = cToK(fToC(f)). You will write less, trust it more, and the compiler will optimise the composition away anyway.

Rankine Conversions

°R = °F + 459.67
°F = °R − 459.67
°R = K × 9/5
K  = °R × 5/9
°R = °C × 9/5 + 491.67

491.67 is 32 × 9/5 + 459.67, i.e. the Rankine value corresponding to 0°C. You will compose these rarely in practice. When you do need Rankine, treat it as “Fahrenheit’s absolute twin” and go through Fahrenheit or Kelvin.

Where Does 9/5 Come From? A Quick Derivation

The two scales are related by an affine function °F = a × °C + b. To solve for a and b, you need two known calibration points. Freezing and boiling are the conventional pair:

Freezing: 0°C ↔ 32°F
Boiling: 100°C ↔ 212°F

Plug both into °F = a × °C + b:

32  = a × 0   + b   →  b = 32
212 = a × 100 + 32  →  a = (212 − 32) / 100 = 180 / 100 = 9/5

That is it — two linear equations, two unknowns, and the whole conversion drops out. The geometric intuition: imagine two vertical thermometers side by side, one in Celsius, one in Fahrenheit. The Fahrenheit thermometer is stretched vertically (slope 9/5) and shifted up (intercept 32) relative to the Celsius one. Every other conversion value sits on that stretched-and-shifted line.

The same derivation with (0°C, 273.15 K) and (100°C, 373.15 K) gives Celsius-to-Kelvin: slope 1, intercept 273.15. The same derivation with any two unambiguous calibration points gives you any affine conversion. Nothing about temperature is special mathematically — the complexity is entirely in the two-anchor-points setup that other unit types do not need.

The −40° Intersection: A Useful Mnemonic

Is there a temperature where Celsius and Fahrenheit read the same? Set °C = °F in the conversion formula:

°C = °C × 9/5 + 32
°C − °C × 9/5 = 32
°C × (1 − 9/5) = 32
°C × (−4/5) = 32
°C = −40

So −40°C = −40°F. Exactly one crossover point, and it happens to be a real temperature you can encounter in Yellowknife, Yakutsk, or Fairbanks in January. It is also a cheap mental check: whenever you are eyeballing a C↔F conversion and the result lands near −40, both numbers should be close to each other. If one says −40°C and the other −72°F, you have a direction bug.

I keep the full mnemonic list taped next to my monitor: freezing (0 / 32), body temp (37 / 98.6), room temp (20 / 68), boiling (100 / 212), −40 (−40 / −40). Five points cover almost every sanity check I need.

Temperature Conversion in Code

The formulas are trivial. Getting them right in a real codebase comes down to two things: preventing a caller from passing Fahrenheit where you wanted Celsius, and making the floating-point behaviour predictable at the boundaries (freezing, absolute zero, oven temperatures). Every example below is a complete, runnable program.

JavaScript / TypeScript

Plain JavaScript gets you functional conversions immediately:

const cToF = (c) => c * 9 / 5 + 32;
const fToC = (f) => (f - 32) * 5 / 9;
const cToK = (c) => c + 273.15;
const kToC = (k) => k - 273.15;
const fToK = (f) => cToK(fToC(f));
const kToF = (k) => cToF(kToC(k));
const cToR = (c) => (c + 273.15) * 9 / 5;
const rToC = (r) => r * 5 / 9 - 273.15;

console.log(cToF(100));   // 212
console.log(fToC(98.6));  // 37
console.log(kToC(300));   // 26.85

TypeScript lets you make unit confusion a compile error by branding the number type:

type Scale = 'C' | 'F' | 'K' | 'R';
type Temp<S extends Scale> = number & { readonly __scale: S };

const t = <S extends Scale>(value: number, _scale: S): Temp<S> =>
  value as Temp<S>;

const cToF = (c: Temp<'C'>): Temp<'F'> => t(c * 9 / 5 + 32, 'F');
const fToC = (f: Temp<'F'>): Temp<'C'> => t((f - 32) * 5 / 9, 'C');

const indoor = t(22, 'C');
const outdoor = cToF(indoor);   // OK: Temp<'F'>
// const broken = cToF(outdoor); // Compile error: Temp<'F'> is not Temp<'C'>

Branded types have zero runtime cost and cost you about ten lines of boilerplate. In exchange, the Toronto bug from the opening paragraph becomes a red squiggle in your editor.

Python

Plain functions work fine, but an Enum plus dataclass pays for itself the first time you log a temperature:

from dataclasses import dataclass
from enum import Enum

class Scale(Enum):
    C = "°C"
    F = "°F"
    K = "K"
    R = "°R"

@dataclass(frozen=True)
class Temperature:
    value: float
    scale: Scale

    def to(self, target: Scale) -> "Temperature":
        c = _to_celsius(self)
        return _from_celsius(c, target)

    def __str__(self) -> str:
        return f"{self.value:.2f}{self.scale.value}"

def _to_celsius(t: Temperature) -> float:
    if t.scale is Scale.C: return t.value
    if t.scale is Scale.F: return (t.value - 32) * 5 / 9
    if t.scale is Scale.K: return t.value - 273.15
    if t.scale is Scale.R: return (t.value - 491.67) * 5 / 9
    raise ValueError(f"Unknown scale: {t.scale}")

def _from_celsius(c: float, scale: Scale) -> Temperature:
    if scale is Scale.C: return Temperature(c, scale)
    if scale is Scale.F: return Temperature(c * 9 / 5 + 32, scale)
    if scale is Scale.K: return Temperature(c + 273.15, scale)
    if scale is Scale.R: return Temperature(c * 9 / 5 + 491.67, scale)
    raise ValueError(f"Unknown scale: {scale}")

body = Temperature(37, Scale.C)
print(body.to(Scale.F))   # 98.60°F
print(body.to(Scale.K))   # 310.15K

If you are crunching scientific data where 0.1 + 0.2 != 0.3 becomes an audit issue, swap float for decimal.Decimal. The tradeoff is speed (Decimal is roughly 50x slower) and the fact that 5/9 has no exact decimal representation either, so you need Decimal(5) / Decimal(9) with a controlled context. For most sensor pipelines, float plus round(value, 2) at the display boundary is enough.

Go

Go’s type system lets you go further than TypeScript: a named float64 type cannot be silently mixed with another named float64 type, even though they share the same runtime representation.

package main

import "fmt"

type Celsius float64
type Fahrenheit float64
type Kelvin float64
type Rankine float64

func (c Celsius) ToFahrenheit() Fahrenheit { return Fahrenheit(c*9/5 + 32) }
func (c Celsius) ToKelvin() Kelvin         { return Kelvin(c + 273.15) }
func (f Fahrenheit) ToCelsius() Celsius    { return Celsius((f - 32) * 5 / 9) }
func (k Kelvin) ToCelsius() Celsius        { return Celsius(k - 273.15) }
func (f Fahrenheit) ToKelvin() Kelvin      { return f.ToCelsius().ToKelvin() }

func main() {
    room := Celsius(22)
    fmt.Printf("%.2f °F\n", room.ToFahrenheit()) // 71.60 °F
    fmt.Printf("%.2f K\n", room.ToKelvin())      // 295.15 K

    // var bug Fahrenheit = room          // compile error
    // fmt.Println(room.ToKelvin() + 1)   // compile error: Kelvin + untyped int needs Kelvin(1)
}

The cost is roughly one line per scale. The benefit is that ToFahrenheit cannot accept a Kelvin value by accident, and a function that takes Celsius will refuse a raw float64 at the call site.

Rust

Rust’s newtype pattern gives you the same guarantees as Go, plus cheap From/Into conversions:

#[derive(Clone, Copy, Debug, PartialEq)]
struct Celsius(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Fahrenheit(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Kelvin(f64);

impl From<Celsius> for Fahrenheit {
    fn from(c: Celsius) -> Self { Fahrenheit(c.0 * 9.0 / 5.0 + 32.0) }
}

impl From<Fahrenheit> for Celsius {
    fn from(f: Fahrenheit) -> Self { Celsius((f.0 - 32.0) * 5.0 / 9.0) }
}

impl From<Celsius> for Kelvin {
    fn from(c: Celsius) -> Self { Kelvin(c.0 + 273.15) }
}

impl From<Kelvin> for Celsius {
    fn from(k: Kelvin) -> Self { Celsius(k.0 - 273.15) }
}

fn main() {
    let body = Celsius(37.0);
    let body_f: Fahrenheit = body.into();
    let body_k: Kelvin = body.into();
    println!("{:.2} {:?} {:?}", body.0, body_f, body_k);
    // 37.00 Fahrenheit(98.6) Kelvin(310.15)
}

You can layer validation on top: a TryFrom<f64> for Kelvin that rejects negative values returns Result<Kelvin, TemperatureError> and pushes the check to construction time. Invalid states never reach your business logic.

SQL (PostgreSQL)

Store temperatures with CHECK constraints and derive alternative units as generated columns. That way a negative Kelvin value is a constraint violation at insert, not a silent data bug three queries downstream.

CREATE OR REPLACE FUNCTION c_to_f(c numeric) RETURNS numeric AS $$
    SELECT c * 9.0 / 5.0 + 32.0;
$$ LANGUAGE SQL IMMUTABLE;

CREATE OR REPLACE FUNCTION c_to_k(c numeric) RETURNS numeric AS $$
    SELECT c + 273.15;
$$ LANGUAGE SQL IMMUTABLE;

CREATE TABLE sensor_readings (
    id          bigserial PRIMARY KEY,
    recorded_at timestamptz NOT NULL DEFAULT now(),
    celsius     numeric(6, 2) NOT NULL,
    fahrenheit  numeric(6, 2) GENERATED ALWAYS AS (c_to_f(celsius)) STORED,
    kelvin      numeric(6, 2) GENERATED ALWAYS AS (c_to_k(celsius)) STORED,
    CONSTRAINT  kelvin_non_negative CHECK (celsius >= -273.15)
);

INSERT INTO sensor_readings (celsius) VALUES (22.5), (0), (100);
SELECT celsius, fahrenheit, kelvin FROM sensor_readings;
-- 22.50 | 72.50  | 295.65
--  0.00 | 32.00  | 273.15
-- 100.00| 212.00 | 373.15

-- Rejected at insert time:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED trades a little disk for query-time speed — you read the value, you do not recompute it. For high-volume IoT tables, swap STORED for a view if disk pressure matters more than read latency.

Handling Weather & IoT APIs

The most common production bug with temperature is not a formula error. It is a unit mismatch between what an API returns and what your UI displays. The providers most developers hit:

OpenWeatherMap returns Kelvin by default. Pass units=metric for Celsius or units=imperial for Fahrenheit. If you forget the query parameter, you get Kelvin. Numbers like 284.15 arriving in a field named temp have fooled enough engineers that it is worth an integration test.

Open-Meteo returns Celsius by default and accepts temperature_unit=fahrenheit. No Kelvin option — it is not a scientific API.

Tomorrow.io and WeatherAPI default to metric but return both scales in the same response under different keys. Read the actual key your code references, not the neighbour.

The pattern I use for any weather or sensor ingestion:

type Reading = {
  value: number;
  scale: 'C' | 'F' | 'K';
  source: string;
};

function normalise(raw: Reading): number /* celsius */ {
  switch (raw.scale) {
    case 'C': return raw.value;
    case 'F': return (raw.value - 32) * 5 / 9;
    case 'K': return raw.value - 273.15;
  }
}

// At ingestion, every reading carries its scale explicitly.
// The UI layer never guesses — it consumes celsius and formats per user preference.

Two rules flow from this:

Every ingestion boundary records the source scale. No bare numbers crossing module lines.
The display layer is the only place that converts to the user’s preferred unit.

Double conversion — where two layers each “normalise” the number — is the other frequent bug. A backend team converts Kelvin to Celsius on write. A frontend team, unaware, applies the same - 273.15 on read. Users see temperatures around −251°C. The fix is a single owner for normalisation, not more tests.

For IoT, raw sensor data often arrives as an ADC count that must be converted to temperature via a calibration curve (for a 10kΩ NTC thermistor, that means the Steinhart–Hart equation). Temperature scale conversions happen after that, on the already-calibrated value. Mixing the two phases is how you end up with numbers that look temperature-shaped but are off by 30%.

Common Pitfalls & How to Avoid Them

These six show up in real production codebases. Check yours against them.

Using the Wrong Formula Direction

Common symptom: an app that shows 37°C baby fever and then flags it as critical. What happened is the API returned 37°F, someone labelled it celsius because the column name said so, and the medical threshold logic compared against a Celsius scale. Prevent this by making the type carry the unit, not the variable name.

Treating Temperature as Extensive

averageTemperature makes sense. sumTemperatures does not. If your aggregation SQL has SUM(temperature_c), something is wrong — you probably want AVG or, in rare cases, an integrated degree-day metric. Temperature is an intensive quantity; do not add two of them and expect a meaningful result.

Floating-Point Rounding

(37 * 9 / 5) + 32 in JavaScript gives 98.60000000000001, not 98.6. Every language that uses IEEE 754 doubles has the same behaviour. Options:

Display with .toFixed(2) (or your language’s equivalent) and stop there.
Use a decimal library (decimal.js, Python Decimal, BigDecimal) for audit-grade accuracy.
Store as integers in deci-degrees (370 instead of 37.0) and divide only at display.

For display in a UI, toFixed(2) is the right call. For a billing or regulatory system where rounding errors accumulate, use decimals.

Negative Kelvin in Input Validation

Kelvin is non-negative by physical law. A request body containing { "tempK": -10 } is always invalid. Enforce this at the boundary — JSON schema, Pydantic, Zod, CHECK constraint — not deep inside business logic. The one exception, quantum systems with “negative absolute temperature”, does not come up in any API you are likely to integrate; if it does, you already know it does.

Missing Unit Labels in UI and Logs

A log line that reads sensor 42: 37 is useless six months later. Is that Celsius? Fahrenheit? A raw ADC count? Always write sensor 42: 37°C or structure the log as { "sensor": 42, "value": 37, "unit": "celsius" }. Disk space is cheap; three-in-the-morning production triage is not.

Timezone Confusion vs Temperature

Travel apps ship this bug: when a user crosses a timezone, the code helpfully shifts every timestamped field — including temperature readings. Temperature does not care about timezones. The timestamp on a reading needs timezone logic; the reading value does not. Keep them in separate fields, pass them through separate conversion pipelines.

Mental Math Shortcuts

For when you do not have a converter open.

Celsius to Fahrenheit (rough): double it, add 30. 20°C → 70°F (actual 68). 30°C → 90°F (actual 86). Accurate to within 2–3°F across 0–40°C, which covers every temperature you experience outside a kiln.

Fahrenheit to Celsius (rough): subtract 30, halve it. 80°F → 25°C (actual 26.7). 60°F → 15°C (actual 15.6). Same accuracy band.

Celsius to Kelvin: add 273 and round. You lose 0.15 K, which is below thermometer precision for anything outside a physics lab.

Two anchors worth memorising: 20°C = 68°F ≈ 293 K, and 100°C = 212°F = 373.15 K. From those two, linear interpolation gets you close enough for any estimate.

The quick-and-dirty rules cover travel, cooking rough-ins, and weather forecasts. For anything that goes into code or a regulatory filing, use the exact formulas — or open our free temperature conversion tool and copy the precise value.

Reference Tables

Everyday Temperatures

Context	Celsius	Fahrenheit	Kelvin
Home freezer	−18°C	0°F	255.15 K
Freezing point	0°C	32°F	273.15 K
Refrigerator	4°C	39°F	277.15 K
Room temperature	20°C	68°F	293.15 K
Body temperature	37°C	98.6°F	310.15 K
Fever threshold	38°C	100.4°F	311.15 K
Hot summer day	35°C	95°F	308.15 K
Water boils	100°C	212°F	373.15 K

Cooking & Oven Conversions

Oven preset	Celsius	Fahrenheit
Low / slow cook	125°C	257°F
Warm baking	150°C	302°F
Moderate baking	175°C	347°F
Standard baking (cakes)	180°C	356°F
Roasting	190°C	374°F
Hot roasting	200°C	392°F
High roasting	220°C	428°F
Pizza / bread crust	250°C	482°F

American recipes round 350°F to 175°C or 180°C depending on the cookbook; the exact value is 176.67°C. Either choice works — home ovens rarely hold temperature to better than ±5°C anyway.

Scientific Extremes

Phenomenon	Kelvin	Celsius
Absolute zero (theoretical floor)	0 K	−273.15°C
Cosmic microwave background	2.725 K	−270.425°C
Liquid helium (boiling, 1 atm)	4.2 K	−268.95°C
Superconductor transition (YBCO)	93 K	−180.15°C
Liquid nitrogen (boiling)	77 K	−196.15°C
Deep space shadow	~40 K	~−233°C
Dry ice (sublimation)	194.65 K	−78.5°C
Sun’s surface	5,778 K	5,504.85°C
Sun’s core	1.57×10⁷ K	1.57×10⁷ °C*
Tokamak plasma (ITER target)	1.5×10⁸ K	~1.5×10⁸ °C*

*At these magnitudes, the 273.15 K offset is a rounding error — Celsius and Kelvin read effectively identical.

FAQ

What is the formula to convert Celsius to Fahrenheit?

Multiply Celsius by 9/5 (or 1.8), then add 32: °F = °C × 9/5 + 32. For example, 25°C × 1.8 + 32 = 77°F. The multiplier reflects the 180:100 ratio between the two scales’ spans from freezing to boiling, and the 32 aligns their different zero points.

What is the formula to convert Fahrenheit to Celsius?

Subtract 32 from the Fahrenheit value, then multiply by 5/9: °C = (°F − 32) × 5/9. For 72°F, the calculation is (72 − 32) × 5/9 = 40 × 5/9 ≈ 22.22°C. Subtract first, multiply second — reversing the order gives the wrong answer.

At what temperature are Celsius and Fahrenheit equal?

At −40 degrees exactly. Setting °C = °F in the conversion formula gives °C = °C × 9/5 + 32, which solves to °C = −40. This is the only temperature where the two scales read the same number, and it is a useful sanity-check landmark for both real-world cold snaps and direction-of-conversion bugs.

How do I convert 350°F to Celsius for baking?

350°F equals about 176.67°C. European recipes usually round this to 180°C, and many American-to-metric conversion charts use 175°C. Either will work in a home oven — temperature stability at that range is worse than the rounding error. Use our temperature converter tool for exact values when precision matters.

What is 100°F in Celsius?

100°F ≈ 37.78°C. This is just above normal body temperature (37°C / 98.6°F) and is often flagged as the start of a low-grade fever. Medical guidelines use 38°C / 100.4°F as the true fever threshold, so 100°F is borderline but not yet clinically significant.

Why is absolute zero −273.15°C and not just −273?

Because the 2019 SI redefinition fixed the Boltzmann constant exactly, making −273.15°C the precise computed value of absolute zero rather than a rounded approximation. Before 2019, the Celsius zero was tied to the triple point of water and the 0.15 came from measurement. Now it is exact by definition.

When should I use Kelvin instead of Celsius in code?

Any time you multiply, divide, or raise a temperature to a power — blackbody radiation (T⁴), ideal gas calculations, reaction rates. Kelvin never goes negative, so division stays stable. For temperature differences, Celsius and Kelvin are interchangeable (a 5-degree change is the same in both).

Is Rankine still used in 2026?

Yes, but narrowly. US mechanical, HVAC, and aerospace engineering still use Rankine for thermodynamic cycle analysis where all other inputs are in Fahrenheit. Outside those fields and outside the United States, it is effectively dead. If you are writing general-purpose software, supporting Rankine is cheap insurance but rarely load-bearing.

How do I convert temperature in a SQL query?

Inline the formula or use a GENERATED ALWAYS AS column. Example: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. The 9.0 and 5.0 (not 9 and 5) force floating-point arithmetic in most dialects; integer division will silently truncate. Add a CHECK (celsius >= -273.15) to reject nonsense values at insert.

What’s the easiest way to convert Celsius to Fahrenheit in my head?

Double the Celsius value and add 30. 22°C × 2 + 30 = 74°F (actual 71.6°F). Accurate to within about 2°F for the 0–30°C range, which covers almost all weather and indoor readings. For the reverse, subtract 30 from Fahrenheit and halve it.

Why does my temperature converter return 98.599999 for 37°C?

Because 9/5 = 1.8 cannot be represented exactly in binary floating-point, so 37 × 9 / 5 + 32 comes out as 98.60000000000001 rather than 98.6. This is IEEE 754 behaviour, not a bug. Use toFixed(2) for display, or switch to a decimal library if trailing-digit precision matters in your domain.

Can I store temperatures as integers to avoid floating-point issues?

Yes — store deci-Celsius (the temperature times 10). 37.0°C becomes 370, 22.5°C becomes 225. Integer math is exact, and you divide by 10 only at the display boundary. This pattern is common in embedded systems and high-volume time-series databases where disk and CPU matter.

How do I handle unit-less numbers in an API response?

Do not. Every temperature field should carry an explicit unit, either in the field name (temp_celsius, temp_k) or in a sibling unit field. If you are the consumer and the API does not provide this, document the assumption loudly in code and write a contract test that breaks if the API’s default changes.

What’s the boiling point of water in all four scales?

100°C = 212°F = 373.15 K = 671.67°R, at standard atmospheric pressure (one atmosphere, 101.325 kPa). Pressure matters: at Denver’s elevation, water boils around 95°C; at the top of Everest, closer to 71°C. Boiling point is a pressure-dependent quantity, not a universal constant.

Does temperature affect floating-point calculations differently than other numbers?

No — temperature values behave like any other floating-point number. The practical gotcha is that the 5/9 and 9/5 factors in the conversion formulas introduce rounding error at every conversion step. For Kelvin values in the 200–400 range, precision is plenty. For sub-zero Celsius values near the edge of representable doubles, precision stays fine too. The real pitfall is chained conversions accumulating small errors — convert once and store the canonical form.