Conversão de temperatura: Celsius, Fahrenheit, Kelvin

Você sobe um painel de clima na segunda. Na quarta, um usuário em Toronto abre um bug: o app mostra a temperatura externa como 284. O endpoint da OpenWeatherMap devolveu Kelvin (é o default), sua interface esperava Celsius e nenhuma camada do meio se preocupou em checar. Uma subtração esquecida, um print queimando no Twitter.

Se você só precisa das duas fórmulas e quer seguir em frente:

Fórmula Celsius para Fahrenheit: °F = °C × 9/5 + 32
Fórmula Fahrenheit para Celsius: °C = (°F − 32) × 5/9
Celsius para Kelvin: K = °C + 273.15

Essas três dão conta de uns 90% do que um dev encontra no dia a dia. O resto deste guia é o outros 10%: de onde vem o 9/5, por que Kelvin nunca é negativo, como fazer seu sistema de tipos rejeitar celsiusToFahrenheit(kelvinValue) já na compilação e como não cair de novo no bug de Toronto. Se o que você quer é só um número agora, pule a leitura e use nosso conversor de temperatura. Para unidades que não sejam de temperatura, olha o guia completo de conversão de unidades.

Por que temperatura é diferente de outras conversões de unidade

Quase toda conversão de unidade é linear passando pelo zero. Um metro vale 3,28084 pés, fim. Dobrou os metros, dobrou os pés. Zero metros, zero pés. Dá para montar uma biblioteca de conversão com uma constante multiplicativa por par e nunca mais olhar para ela.

Temperatura quebra esse modelo num ponto chave: as escalas não têm o mesmo zero. O Celsius ancora o zero no congelamento da água. O Fahrenheit ancora num mistura de salmoura de 1724. O Kelvin ancora no piso teórico da termodinâmica. Para ir de uma a outra você precisa de fator de escala e deslocamento — temperatura é uma transformação afim, não linear.

A consequência é concreta e perigosa: valores de temperatura não se somam como comprimento ou massa. 20°C + 20°C não dá 40°C em nenhum sentido físico. Você não “soma dois cômodos” e obtém um cômodo mais quente. Somar uma diferença de temperatura a uma temperatura, isso sim funciona, porque diferenças são lineares. Essa distinção foi o que provocou o incidente da vacina Medeva no Reino Unido em 2006: um registrador de cadeia de frio farmacêutica confundiu leitura absoluta com delta e marcou milhares de doses como fora da especificação. Grandezas intensivas como a temperatura exigem essa trava mental: números que compartilham unidade não compartilham automaticamente álgebra.

As quatro escalas de temperatura explicadas

No código do dia a dia só duas escalas importam (Celsius, Fahrenheit), uma terceira entra em qualquer coisa científica (Kelvin) e a quarta aparece em exatamente um lugar: livros-texto de termodinâmica dos EUA e as bases de código de HVAC que ainda os citam.

Celsius (°C)

Anders Celsius publicou sua escala em 1742, originalmente com 0° na fervura e 100° no congelamento — invertido em relação ao que usamos hoje. A orientação moderna, com 0°C no congelamento da água e 100°C na fervura sob uma atmosfera padrão, surgiu pouco depois da morte dele. Hoje é a unidade derivada do SI para temperatura cotidiana e a escala padrão em todo país, exceto Estados Unidos, Bahamas, Belize, Ilhas Cayman e Libéria.

A redefinição do SI em 2019 amarrou o Celsius rigorosamente ao Kelvin: 0°C agora vale exatamente 273,15 K. O ponto de congelamento da água, antes a definição, virou uma consequência medida (cai em 0°C com precisão de partes por milhão, mas não é mais a âncora).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit propôs sua escala em 1724. Ele colocou o 0°F no congelamento de uma mistura específica de salmoura — a temperatura mais fria que conseguia reproduzir de forma confiável num inverno de Danzig — e 96°F na temperatura corporal. Recalibrações posteriores contra os pontos de congelamento e fervura da água pura empurraram a temperatura corporal para 98,6°F e fixaram o congelamento em 32°F e a fervura em 212°F, um intervalo de 180 graus.

O Fahrenheit sobrevive nos Estados Unidos em clima, culinária e uso médico. Os 180 graus entre congelamento e fervura (contra 100 no Celsius) às vezes são defendidos como “resolução mais fina para temperaturas ambientes” — um argumento marginal, mas que explica por que termostatos americanos vêm marcados em passos de 1°F enquanto os europeus usam passos de 0,5°C.

Kelvin (K)

William Thomson, Lord Kelvin, propôs uma escala absoluta em 1848. O Kelvin moderno é a unidade base do SI para temperatura. A redefinição do SI em 2019 amarrou o kelvin à constante de Boltzmann k_B = 1.380649 × 10⁻²³ J/K de forma exata, transformando-a em quantidade definida em vez de medida.

O Kelvin tem três peculiaridades que o dev precisa saber:

Sem símbolo de grau. Escreva 300 K, não 300°K. É a convenção do SI desde 1967.
Começa no zero absoluto. 0 K = −273,15°C. Nunca deveria aparecer Kelvin negativo em dados válidos; trate como erro de entrada.
Mesmo tamanho de grau que o Celsius. Uma variação de 1 K equivale a 1°C. Diferenças de temperatura são intercambiáveis entre os dois; só os valores absolutos diferem pelo deslocamento de 273,15.

Kelvin é a escolha certa sempre que você multiplica ou divide temperaturas — radiação térmica (T⁴), lei dos gases ideais, física de corpo negro. Dividir por um Celsius negativo ou próximo de zero explode fórmulas físicas que você quase sempre quer manter finitas.

Rankine (°R)

William Rankine propôs essa escala em 1859 como o equivalente do Kelvin em Fahrenheit: escala absoluta, zero no zero absoluto, mas com graus do tamanho do Fahrenheit. 0°R = −459,67°F. 491,67°R = 0°C.

Rankine só aparece na engenharia termodinâmica dos EUA — cálculos de HVAC, refino de petróleo, análise de combustão de motores de foguete — onde os cálculos pedem uma escala absoluta, mas os dados de entrada vêm em Fahrenheit. A conversão é mecânica: °R = °F + 459,67, ou °R = K × 9/5. A maioria do software de engenharia moderno fica em Kelvin internamente e converte só na hora de exibir, e é isso que eu recomendo quando dá.

Fórmulas de conversão de temperatura (todas as seis direções)

Seis direções, quatro escalas, seis fórmulas. Na prática, decore as centradas em Celsius e componha o resto.

Celsius para Fahrenheit e de volta

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

O fator 9/5 é a razão entre os intervalos das duas escalas sobre os mesmos dois marcos físicos. Do congelamento à fervura, o Fahrenheit cobre 180 graus (32 a 212); o Celsius cobre 100 (0 a 100). 180 / 100 = 9/5 = 1,8. O + 32 é o deslocamento que alinha os zeros no ponto de congelamento, porque o zero do Fahrenheit fica 32°F abaixo do zero do Celsius.

Exemplo resolvido: °F = 25 × 9/5 + 32 = 45 + 32 = 77°F.

Celsius para Kelvin e de volta

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

Sem fator de escala, só deslocamento. 273,15 é a distância numérica do zero do Celsius (congelamento da água) até o zero absoluto, medida em graus Celsius. Como Kelvin e Celsius têm o mesmo tamanho de grau, não entra multiplicador.

Fahrenheit para Kelvin e de volta

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

Não tem forma mais curta — precisa de mudança de escala e de deslocamento. No código, quase sempre sai mais limpo passar por Celsius: k = cToK(fToC(f)). Você escreve menos, confia mais e o compilador otimiza a composição de qualquer jeito.

Conversões de Rankine

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

491,67 é 32 × 9/5 + 459,67, ou seja, o valor em Rankine que corresponde a 0°C. Raramente você vai compor essas fórmulas na prática. Quando precisar de Rankine, trate como “o gêmeo absoluto do Fahrenheit” e passe por Fahrenheit ou Kelvin.

De onde vem o 9/5? Uma derivação rápida

As duas escalas se relacionam por uma função afim °F = a × °C + b. Para achar a e b, você precisa de dois pontos de calibração conhecidos. Congelamento e fervura formam o par convencional:

Congelamento: 0°C ↔ 32°F
Fervura: 100°C ↔ 212°F

Substitua os dois em °F = a × °C + b:

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

Pronto — duas equações lineares, duas incógnitas, e toda a conversão cai no colo. A intuição geométrica: imagine dois termômetros verticais lado a lado, um em Celsius, outro em Fahrenheit. O termômetro Fahrenheit está esticado verticalmente (inclinação 9/5) e deslocado para cima (intercepto 32) em relação ao Celsius. Qualquer valor de conversão está em cima dessa reta esticada e deslocada.

A mesma derivação com (0°C, 273,15 K) e (100°C, 373,15 K) dá o Celsius-para-Kelvin: inclinação 1, intercepto 273,15. A mesma derivação com quaisquer dois pontos de calibração inequívocos te dá qualquer conversão afim. Temperatura não tem nada matematicamente especial — a complicação está toda na configuração de dois pontos de âncora, que outras unidades não precisam.

A interseção em −40°: um mnemônico útil

Existe uma temperatura em que Celsius e Fahrenheit marcam o mesmo número? Faça °C = °F na fórmula de conversão:

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

Logo −40°C = −40°F. Um único ponto de cruzamento, e é uma temperatura real que você encontra em Yellowknife, Yakutsk ou Fairbanks em janeiro. Também serve como teste mental barato: sempre que você olha por cima uma conversão C↔F e o resultado chega perto de −40, os dois números precisam estar próximos. Se um diz −40°C e o outro −72°F, tem um bug de direção no caminho.

Eu mantenho a lista completa de mnemônicos colada no monitor: congelamento (0 / 32), temperatura corporal (37 / 98,6), temperatura ambiente (20 / 68), fervura (100 / 212), −40 (−40 / −40). Cinco pontos cobrem praticamente toda verificação de sanidade que eu preciso.

Conversão de temperatura em código

As fórmulas são triviais. Acertá-las numa base de código real se resume a duas coisas: impedir que quem chama passe Fahrenheit onde você esperava Celsius e deixar o comportamento de ponto flutuante previsível nos limites (congelamento, zero absoluto, temperaturas de forno). Todo exemplo abaixo é um programa completo e executável.

JavaScript / TypeScript

JavaScript puro já resolve conversão funcional na hora:

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

No TypeScript dá para transformar confusão de unidade em erro de compilação marcando o tipo número:

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); // Erro de compilação: Temp<'F'> não é Temp<'C'>

Tipos marcados (branded) têm custo zero em runtime e pedem umas dez linhas extras. Em troca, o bug de Toronto do parágrafo de abertura vira um sublinhado vermelho no seu editor.

Python

Funções soltas dão conta do recado, mas um Enum casado com dataclass se paga na primeira vez que você loga uma temperatura:

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"Escala desconhecida: {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"Escala desconhecida: {scale}")

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

Se você processa dados científicos em que 0.1 + 0.2 != 0.3 vira problema de auditoria, troque float por decimal.Decimal. O preço é a velocidade (Decimal é algo como 50x mais lento) e o fato de 5/9 também não ter representação decimal exata, então você precisa de Decimal(5) / Decimal(9) com contexto controlado. Para a maioria dos pipelines de sensor, float mais round(value, 2) na hora de exibir resolve com sobra.

Go

O sistema de tipos do Go vai mais longe que o do TypeScript: um float64 nomeado não se mistura silenciosamente com outro float64 nomeado, mesmo que os dois tenham a mesma representação em runtime.

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          // erro de compilação
    // fmt.Println(room.ToKelvin() + 1)   // erro: Kelvin + int sem tipo precisa de Kelvin(1)
}

O custo é tipo uma linha por escala. O benefício é que ToFahrenheit não aceita um valor Kelvin por acidente, e uma função que recebe Celsius recusa um float64 cru no ponto de chamada.

Rust

O padrão newtype do Rust entrega as mesmas garantias do Go, com o bônus de conversões From/Into baratas:

#[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)
}

Dá para empilhar validação em cima: um TryFrom<f64> for Kelvin que rejeita negativos devolve Result<Kelvin, TemperatureError> e empurra a checagem para o momento da construção. Estados inválidos não chegam à sua lógica de negócio.

SQL (PostgreSQL)

Grave temperaturas com restrições CHECK e derive unidades alternativas como colunas geradas. Assim um valor Kelvin negativo vira violação de restrição no insert, em vez de um bug silencioso de dados três consultas adiante.

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

-- Rejeitado no momento do insert:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED gasta um pouco de disco em troca de velocidade na consulta — você lê o valor em vez de recalcular. Em tabelas IoT de alto volume, troque STORED por uma view se a pressão em disco pesar mais que a latência de leitura.

Lidando com APIs de clima e IoT

O bug mais comum de temperatura em produção não é erro de fórmula. É descasamento de unidade entre o que a API retorna e o que sua UI exibe. Um passeio rápido pelos provedores com que os devs mais esbarram:

OpenWeatherMap retorna Kelvin por padrão. Passe units=metric para Celsius ou units=imperial para Fahrenheit. O ponto crítico: se esquecer o parâmetro na query, você recebe Kelvin. Números como 284.15 chegando num campo chamado temp já enganaram engenheiros suficientes para justificar um teste de integração.

Open-Meteo retorna Celsius por padrão e aceita temperature_unit=fahrenheit. Não tem opção de Kelvin — não é API científica.

Tomorrow.io e WeatherAPI vêm com padrão métrico, mas devolvem as duas escalas na mesma resposta em chaves diferentes. Leia a chave que seu código referencia, não a vizinha.

O padrão que eu uso para qualquer ingestão de clima ou sensor é este:

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;
  }
}

// Na ingestão, toda leitura carrega sua escala explicitamente.
// A camada de UI nunca adivinha — ela consome celsius e formata de acordo com a preferência do usuário.

Duas regras caem dali:

Toda fronteira de ingestão registra a escala de origem. Nenhum número “cru” cruzando linhas de módulo.
A camada de exibição é o único lugar que converte para a unidade preferida do usuário.

Conversão dupla — duas camadas, cada uma “normalizando” o número — é o outro bug recorrente. Uma equipe de back-end converte Kelvin para Celsius ao escrever. Uma equipe de front-end, sem saber, aplica o mesmo - 273.15 ao ler. Os usuários veem temperaturas perto de −251°C. A solução é ter um dono único da normalização, não mais testes.

Em IoT, dados brutos de sensor em geral chegam como uma contagem de ADC que você converte em temperatura via uma curva de calibração (para um termistor NTC de 10kΩ, isso significa a equação de Steinhart–Hart). Conversões de escala de temperatura acontecem depois disso, sobre o valor já calibrado. Misturar as duas fases é como você termina com números que parecem temperatura mas estão 30% fora.

Armadilhas comuns e como evitá-las

Essas seis aparecem em bases de código de produção reais. Confere as suas.

Usar a direção errada da fórmula

Sintoma mais comum: um app que mostra 37°C de febre de bebê e depois sinaliza como crítico. O que aconteceu de verdade: a API devolveu 37°F, alguém rotulou como celsius porque o nome da coluna dizia isso, e a lógica de limite médico comparou contra uma escala Celsius. Para evitar, deixe o tipo carregar a unidade, não o nome da variável.

Tratar temperatura como grandeza extensiva

averageTemperature faz sentido. sumTemperatures não. Se o SQL de agregação tem SUM(temperature_c), tem alguma coisa errada — provavelmente você quer AVG ou, em casos raros, uma métrica integrada de graus-dia. Temperatura é grandeza intensiva; não some duas delas esperando um resultado com significado.

Arredondamento de ponto flutuante

(37 * 9 / 5) + 32 em JavaScript devolve 98.60000000000001, não 98.6. Qualquer linguagem que use doubles IEEE 754 se comporta assim. Opções:

Exibir com .toFixed(2) (ou o equivalente na sua linguagem) e parar por aí.
Usar uma biblioteca decimal (decimal.js, Python Decimal, BigDecimal) para precisão de auditoria.
Guardar como inteiros em deci-graus (370 em vez de 37.0) e dividir só na hora de exibir.

Para exibição em UI, toFixed(2) quase sempre resolve. Num sistema de cobrança ou regulatório, onde erros de arredondamento se acumulam, vai de decimal.

Kelvin negativo na validação de entrada

Kelvin é não-negativo por lei física. Um corpo de requisição com { "tempK": -10 } é sempre inválido. Imponha isso na fronteira — JSON schema, Pydantic, Zod, restrição CHECK — não no fundo da lógica de negócio. A única exceção, sistemas quânticos com “temperatura absoluta negativa”, não vai aparecer em nenhuma API que você vai integrar; se aparecer, você já sabe que aparece.

Rótulos de unidade ausentes na UI e nos logs

Uma linha de log sensor 42: 37 é inútil seis meses depois. Celsius? Fahrenheit? Contagem bruta de ADC? Escreva sempre sensor 42: 37°C ou estruture o log como { "sensor": 42, "value": 37, "unit": "celsius" }. Disco é barato; triagem em produção às três da manhã não é.

Confusão de fuso horário vs. temperatura

Apps de viagem às vezes soltam este bug: quando um usuário cruza um fuso, o código “prestativamente” desloca todo campo com timestamp — inclusive leituras de temperatura. Temperatura não liga para fuso. O timestamp de uma leitura precisa de lógica de fuso; o valor da leitura, não. Mantenha-os em campos separados e passe por pipelines de conversão separados.

Atalhos de cálculo mental

Para quando você não tem um conversor aberto.

Celsius para Fahrenheit (aproximado): dobre o valor e some 30. 20°C → 70°F (real 68). 30°C → 90°F (real 86). Fica dentro de 2 a 3°F entre 0 e 40°C, faixa que cobre quase toda temperatura que você encontra fora de um forno industrial.

Fahrenheit para Celsius (aproximado): tire 30 e divida por 2. 80°F → 25°C (real 26,7). 60°F → 15°C (real 15,6). Mesma faixa de precisão.

Celsius para Kelvin: some 273 e arredonde. Você perde 0,15 K, abaixo da precisão de termômetro para qualquer coisa fora de laboratório de física.

Duas âncoras que vale memorizar: 20°C = 68°F ≈ 293 K, e 100°C = 212°F = 373,15 K. Dessas duas, interpolação linear já te deixa perto o suficiente para qualquer estimativa.

As regras rápidas e sujas cobrem viagens, rabiscos de cozinha e previsão do tempo. Para qualquer coisa que vá parar em código ou processo regulatório, use as fórmulas exatas — ou abra nossa ferramenta gratuita de conversão de temperatura e copie o valor preciso.

Tabelas de referência

Temperaturas do dia a dia

Contexto	Celsius	Fahrenheit	Kelvin
Freezer doméstico	−18°C	0°F	255,15 K
Ponto de congelamento	0°C	32°F	273,15 K
Geladeira	4°C	39°F	277,15 K
Temperatura ambiente	20°C	68°F	293,15 K
Temperatura corporal	37°C	98,6°F	310,15 K
Limite de febre	38°C	100,4°F	311,15 K
Dia quente de verão	35°C	95°F	308,15 K
Água ferve	100°C	212°F	373,15 K

Conversões de cozinha e forno

Predefinição do forno	Celsius	Fahrenheit
Baixo / cozimento lento	125°C	257°F
Assar morno	150°C	302°F
Assar moderado	175°C	347°F
Assar padrão (bolos)	180°C	356°F
Rostir	190°C	374°F
Rostir quente	200°C	392°F
Rostir em alta	220°C	428°F
Pizza / crosta de pão	250°C	482°F

Receitas americanas arredondam 350°F para 175°C ou 180°C dependendo do livro; o valor exato é 176,67°C. Qualquer um dos dois funciona — forno doméstico raramente mantém temperatura com precisão melhor que ±5°C, mesmo.

Extremos científicos

Fenômeno	Kelvin	Celsius
Zero absoluto (piso teórico)	0 K	−273,15°C
Radiação cósmica de fundo	2,725 K	−270,425°C
Hélio líquido (fervura, 1 atm)	4,2 K	−268,95°C
Transição supercondutora (YBCO)	93 K	−180,15°C
Nitrogênio líquido (fervura)	77 K	−196,15°C
Sombra no espaço profundo	~40 K	~−233°C
Gelo seco (sublimação)	194,65 K	−78,5°C
Superfície do Sol	5.778 K	5.504,85°C
Núcleo do Sol	1,57×10⁷ K	1,57×10⁷ °C*
Plasma de tokamak (meta ITER)	1,5×10⁸ K	~1,5×10⁸ °C*

*Nessa ordem de grandeza, o deslocamento de 273,15 K é um erro de arredondamento — Celsius e Kelvin são efetivamente idênticos na leitura.

FAQ

Qual é a fórmula para converter Celsius em Fahrenheit?

Multiplique Celsius por 9/5 (ou 1,8) e some 32: °F = °C × 9/5 + 32. Exemplo: 25°C × 1,8 + 32 = 77°F. O multiplicador reflete a razão 180:100 entre os intervalos das duas escalas do congelamento à fervura, e o 32 alinha os pontos zero diferentes.

Qual é a fórmula para converter Fahrenheit em Celsius?

Subtraia 32 do valor em Fahrenheit e multiplique por 5/9: °C = (°F − 32) × 5/9. Para 72°F, fica (72 − 32) × 5/9 = 40 × 5/9 ≈ 22,22°C. Subtrai primeiro, multiplica depois — inverter a ordem dá resultado errado.

Em que temperatura Celsius e Fahrenheit são iguais?

A exatos −40 graus. Colocar °C = °F na fórmula de conversão dá °C = °C × 9/5 + 32, que resolve em °C = −40. É a única temperatura em que as duas escalas marcam o mesmo número, e serve de sanity check útil tanto para ondas de frio reais quanto para bugs de direção de conversão.

Como converto 350°F em Celsius para assar?

350°F equivale a uns 176,67°C. Receitas europeias costumam arredondar para 180°C, e muitas tabelas de conversão americano-para-métrico usam 175°C. Qualquer um dos dois funciona num forno doméstico — a estabilidade de temperatura nessa faixa é pior que o erro de arredondamento. Use nossa ferramenta de conversão de temperatura para valores exatos quando a precisão importar.

Quanto é 100°F em Celsius?

100°F ≈ 37,78°C. Fica um pouco acima da temperatura corporal normal (37°C / 98,6°F) e costuma ser sinalizado como início de febre baixa. As diretrizes médicas geralmente usam 38°C / 100,4°F como limite real de febre, então 100°F fica na linha de corte, mas ainda sem significado clínico forte.

Por que o zero absoluto é −273,15°C e não só −273?

Porque a redefinição do SI em 2019 fixou a constante de Boltzmann de forma exata, e com isso −273,15°C passou a ser o valor computado exato do zero absoluto em vez de aproximação arredondada. Antes de 2019, o zero Celsius estava ligado ao ponto triplo da água e o 0,15 vinha de medição. Hoje é exato por definição.

Quando devo usar Kelvin em vez de Celsius no código?

Sempre que você multiplicar, dividir ou elevar uma temperatura a uma potência — radiação de corpo negro (T⁴), cálculos de gás ideal, taxas de reação. Kelvin nunca fica negativo, então a divisão se mantém estável. Em diferenças de temperatura, Celsius e Kelvin são intercambiáveis (uma variação de 5 graus é a mesma nos dois).

Rankine ainda é usado em 2026?

Sim, mas em nichos. Engenharias mecânica, HVAC e aeroespacial nos EUA ainda usam Rankine para análise de ciclos termodinâmicos quando todas as outras entradas estão em Fahrenheit. Fora desses campos e fora dos Estados Unidos, está praticamente morto. Em software de propósito geral, suportar Rankine é um seguro barato, raramente crítico.

Como faço conversão de temperatura numa consulta SQL?

Inline a fórmula ou use uma coluna GENERATED ALWAYS AS. Exemplo: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. O 9.0 e 5.0 (em vez de 9 e 5) forçam aritmética de ponto flutuante na maioria dos dialetos; divisão inteira trunca em silêncio. Coloque um CHECK (celsius >= -273.15) para rejeitar valores sem sentido no insert.

Qual é o jeito mais fácil de converter Celsius em Fahrenheit de cabeça?

Dobre o valor em Celsius e some 30. 22°C × 2 + 30 = 74°F (real 71,6°F). Cai dentro de uns 2°F na faixa de 0 a 30°C, que cobre quase toda temperatura ambiente e externa. Para o inverso, tire 30 do Fahrenheit e divida por 2.

Por que meu conversor de temperatura devolve 98.599999 para 37°C?

Porque 9/5 = 1,8 não tem representação exata em ponto flutuante binário, então 37 × 9 / 5 + 32 sai como 98.60000000000001 em vez de 98.6. Isso é comportamento do IEEE 754, não bug. Use toFixed(2) para exibir ou troque por uma biblioteca decimal se precisão de dígitos finais importar no seu domínio.

Posso armazenar temperaturas como inteiros para evitar problemas de ponto flutuante?

Sim — grave deci-Celsius (a temperatura vezes 10). 37,0°C vira 370, 22,5°C vira 225. Matemática inteira é exata, e você divide por 10 só na fronteira de exibição. Esse padrão aparece em sistemas embarcados e bancos de séries temporais de alto volume onde disco e CPU pesam.

Como lidar com números sem unidade numa resposta de API?

Não lide. Todo campo de temperatura precisa carregar unidade explícita, seja no nome do campo (temp_celsius, temp_k), seja num campo unit irmão. Se você é o consumidor e a API não entrega isso, documente a suposição em alto e bom tom no código e escreva um teste de contrato que quebre se o padrão da API mudar.

Qual é o ponto de ebulição da água em todas as quatro escalas?

100°C = 212°F = 373,15 K = 671,67°R, à pressão atmosférica padrão (uma atmosfera, 101,325 kPa). A pressão importa: na altitude de Denver, a água ferve por volta de 95°C; no topo do Everest, algo mais perto de 71°C. Ponto de ebulição é grandeza dependente de pressão, não constante universal.

A temperatura afeta cálculos de ponto flutuante de forma diferente de outros números?

Não — valores de temperatura se comportam como qualquer outro número de ponto flutuante. O pega-ratão prático é que os fatores 5/9 e 9/5 das fórmulas de conversão introduzem erro de arredondamento a cada passo. Para valores em Kelvin na faixa de 200 a 400, a precisão sobra. Para valores Celsius abaixo de zero perto do limite dos doubles representáveis, a precisão também se segura. A armadilha real é o acúmulo de pequenos erros em conversões encadeadas — converta uma vez e guarde na forma canônica.