The single character ℉ looks convenient, but ordinary °F is the form Unicode prefers for normal text. Both are read as Fahrenheit; what changes is the encoding, not the temperature scale.
A font may make the two forms indistinguishable. The difference becomes visible only when measurement text is inspected, searched, normalized, or transferred between systems that care about exact characters.
Two encodings for the same visible unit
| What you see | Stored as | Text structure |
|---|---|---|
| ℉ | U+2109 DEGREE FAHRENHEIT | One code point |
| °F | U+00B0 + U+0046 | DEGREE SIGN + LATIN CAPITAL LETTER F |
In the two-character form, the F is the ordinary uppercase Latin letter U+0046. That matters when validating or generating data: the preferred spelling is not a special Fahrenheit letter, but a degree sign followed by the normal capital F.
Unicode defines a compatibility mapping from U+2109 to the two ordinary characters U+00B0 DEGREE SIGN and U+0046 LATIN CAPITAL LETTER F. NFKC follows that mapping, so ℉ becomes °F.
Why Unicode prefers °F
Unicode recommends using the sequence °F in normal text rather than the dedicated U+2109 character. The reason is compatibility: characters such as ℉ were encoded so Unicode could represent text from older standards that already contained a one-character Fahrenheit symbol.
If you are typing Fahrenheit today, °F is the clearer choice. The same preference exists for the ordinary °C form of Celsius.
Searching and normalizing legacy Fahrenheit text
A literal comparison still distinguishes the original forms. One string contains U+2109; the other contains two code points. NFKC can fold the compatibility character to °F, making matching easier when exact source encoding is not important.
NFC is different. It handles canonical normalization and does not generally replace compatibility characters such as U+2109 with their compatibility decompositions.
An exact-match search for °F may miss text that contains ℉ unless the search system normalizes or explicitly equates the two forms. Unicode recommends treating them as equivalent for searching, but that behavior has to be implemented.
This is a common source of “looks the same, does not match” problems in imported documents, spreadsheets, OCR output, and older databases.
Spacing before °F is a style question
The SI Brochure does not set a spacing convention for Fahrenheit because °F is not an SI unit. Published styles vary: some write 68°F, while others use 68 °F. Follow the style or technical standard that governs the document.
That typography question is separate from the Unicode question. With or without a space before the unit, Unicode prefers the ordinary sequence U+00B0 DEGREE SIGN plus U+0046 LATIN CAPITAL LETTER F over U+2109 ℉ for normal text.
Checking what the text actually contains
If you copied a Fahrenheit mark from a PDF or legacy source, inspect the code points. U+2109 is the single character ℉. U+00B0 followed by U+0046 is °F.
Do not use visual width as the test. A font may draw U+2109 as a compact unit glyph or make it look nearly indistinguishable from the two-character sequence.
Character normalization is not unit conversion
Replacing ℉ with °F standardizes the character sequence; it does not convert the temperature. A value of 68 °F only becomes 20 °C after applying the Fahrenheit-to-Celsius conversion formula.
This distinction matters in cleanup scripts. Unicode normalization can standardize text representation, but it cannot infer or change the numerical quantity.
Handling a collection that contains both forms
A mixed collection does not need one universal treatment. For an archive, U+2109 may be part of the source record. For a catalogue, search index, or maintained dataset, using the Unicode-preferred °F sequence for comparison avoids splitting equivalent labels.
When provenance matters, keep the original value and derive a second value for matching. That way the source stays intact without forcing users to know whether a Fahrenheit label came from one code point or two.
Text normalization should leave the numerical value alone. If a cell contains 68℉, converting U+2109 to °F should produce 68°F or the spacing required by the chosen style—not a Celsius value and not a different number.
Keeping those operations separate prevents a text-cleanup step from quietly becoming a numerical transformation.
Why ℉ has not disappeared
Compatibility characters do not disappear simply because a preferred representation exists. Older files, conversion tools, fonts, and data exports can continue to carry U+2109 forward. A modern application may therefore encounter ℉ even if nobody deliberately chose it during recent editing.
That is one reason Unicode recommends equivalence for searching. Users generally mean the same Fahrenheit notation whether the source stores U+2109 or the two-character sequence, so search behavior should not force them to know the encoding history first.
When keeping ℉ makes sense
Keep U+2109 when exact transcription or a legacy format requires it. For new and routinely maintained text, the ordinary °F sequence is easier to type, search, and normalize consistently.
If the raised circle itself looks suspicious, the degree sign vs ordinal vs ring-above guide covers several other characters that can be mistaken for °.