UNICHAR
Quirk foundCategory: Text · Last tested 2026-09-01
Real compatibility results for the UNICHAR function: executed in Excel for the web, Google Sheets and LibreOffice Calc, with desktop Excel behavior from Microsoft’s official documentation (we do not run desktop Excel — Excel for the web is a different application and is executed separately). Syntax and links to that documentation are below.
Support matrix
| Engine | Documented | Live-tested | Verdict |
|---|---|---|---|
| Excel (desktop) | Yes | No — documented only | n/a |
| Excel for the web | — | Yes (recalc, 2026-09-01) | Supported, behaves as documented |
| Google Sheets | Yes | Yes (Drive import, 2026-08-29) | Supported, behaves as documented |
| LibreOffice Calc | Yes | Yes (25.8.7.3, 2026-07-29) | Quirk found |
LibreOffice version history
We executed the same test cases under each LibreOffice release to show exactly when UNICHAR’s support changed — not documentation claims, real results.
| LibreOffice version | Verdict | Tested |
|---|---|---|
| 24.2.0.3 | Quirk found | 2026-08-29 |
| 24.8.7.2 | Quirk found | 2026-08-29 |
| 25.2.0.3 | Quirk found | 2026-08-29 |
| 25.8.7.3 | Quirk found | 2026-07-29 |
Why isn't UNICHAR working in LibreOffice?
UNICHAR exists in LibreOffice 25.8.7.3, but it is not a drop-in match for
Excel — our executed tests found real behavioral differences (detailed in the test results on this
page). If a formula that works in Excel or Google Sheets misbehaves in LibreOffice, compare your usage
against the failing cases above before assuming your data is wrong.
Discovered quirks
-
=UNICHAR(0) on
LibreOffice Calc returned
_x0000_, but the documented/expected
result is #VALUE!.
Provenance
MISMATCH vs expected: expected '#VALUE!', got '_x0000_'
Executed test cases
Excel for the web (executed 2026-09-01 via OneDrive recalculation)
These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =UNICHAR(233) | Basic code point beyond the 7-bit ASCII/basic-Latin range (U+00E9 'e with acute') | é | éProvenanceU+00E9 = 233 decimal = accented lowercase e (e-acute) |
Matched |
| =UNICHAR(UNICODE("é")) | Round trip: UNICODE() extracts the code point of an accented character, UNICHAR() converts it straight back | é | éProvenanceUNICODE(char) then UNICHAR(that number) must reproduce the original character exactly |
Matched |
| =UNICHAR(128512) | Code point beyond the Basic Multilingual Plane (U+1F600 GRINNING FACE emoji), requiring a UTF-16 surrogate pair internally | 😀 | 😀Provenance128512 decimal = U+1F600, the grinning-face emoji; modern Excel supports supplementary-plane code points via surrogate pairs |
Matched |
| =UNICHAR(0) | UNICHAR(0) is documented to raise #VALUE! (0 is not a valid character code point). Verified via https://support.microsoft.com/en-us/office/unichar-function-ffeb64f5-f131-44c6-b332-5cd72f0659b8 ("Number: ... Numbers <=0 ... UNICHAR returns the #VALUE! error value") | #VALUE! | #VALUE! | Matched |
| =UNICHAR(-1) | Negative code point is out of range -> #VALUE! per the same UNICHAR documentation as UNICHAR_zero_error | #VALUE! | #VALUE! | Matched |
Google Sheets (executed 2026-08-29 via Drive import)
Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =UNICHAR(233) | Basic code point beyond the 7-bit ASCII/basic-Latin range (U+00E9 'e with acute') | é | éProvenanceU+00E9 = 233 decimal = accented lowercase e (e-acute) |
Matched |
| =UNICHAR(UNICODE("é")) | Round trip: UNICODE() extracts the code point of an accented character, UNICHAR() converts it straight back | é | éProvenanceUNICODE(char) then UNICHAR(that number) must reproduce the original character exactly |
Matched |
| =UNICHAR(128512) | Code point beyond the Basic Multilingual Plane (U+1F600 GRINNING FACE emoji), requiring a UTF-16 surrogate pair internally | 😀 | 😀Provenance128512 decimal = U+1F600, the grinning-face emoji; modern Excel supports supplementary-plane code points via surrogate pairs |
Matched |
| =UNICHAR(0) | UNICHAR(0) is documented to raise #VALUE! (0 is not a valid character code point). Verified via https://support.microsoft.com/en-us/office/unichar-function-ffeb64f5-f131-44c6-b332-5cd72f0659b8 ("Number: ... Numbers <=0 ... UNICHAR returns the #VALUE! error value") | #VALUE! | #VALUE! | Matched |
| =UNICHAR(-1) | Negative code point is out of range -> #VALUE! per the same UNICHAR documentation as UNICHAR_zero_error | #VALUE! | #VALUE! | Matched |
LibreOffice Calc 25.8.7.3 (tested 2026-07-29)
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =UNICHAR(233) | Basic code point beyond the 7-bit ASCII/basic-Latin range (U+00E9 'e with acute') | é | éProvenanceU+00E9 = 233 decimal = accented lowercase e (e-acute) |
Matched |
| =UNICHAR(UNICODE("é")) | Round trip: UNICODE() extracts the code point of an accented character, UNICHAR() converts it straight back | é | éProvenanceUNICODE(char) then UNICHAR(that number) must reproduce the original character exactly |
Matched |
| =UNICHAR(128512) | Code point beyond the Basic Multilingual Plane (U+1F600 GRINNING FACE emoji), requiring a UTF-16 surrogate pair internally | 😀 | 😀Provenance128512 decimal = U+1F600, the grinning-face emoji; modern Excel supports supplementary-plane code points via surrogate pairs |
Matched |
| =UNICHAR(0) | UNICHAR(0) is documented to raise #VALUE! (0 is not a valid character code point). Verified via https://support.microsoft.com/en-us/office/unichar-function-ffeb64f5-f131-44c6-b332-5cd72f0659b8 ("Number: ... Numbers <=0 ... UNICHAR returns the #VALUE! error value") | _x0000_ | #VALUE! | Mismatch |
| =UNICHAR(-1) | Negative code point is out of range -> #VALUE! per the same UNICHAR documentation as UNICHAR_zero_error | #VALUE! | #VALUE! | Matched |
Docs & syntax
- Excel (desktop): official documentation
- Google Sheets: official documentation
- LibreOffice Calc: official documentation
Where UNICHAR behaves differently
- CHAR(0) and UNICHAR(0): Excel #VALUE! vs a NUL character in LibreOffice
Excel documents CHAR(0) and UNICHAR(0) as #VALUE!. LibreOffice Calc returns a NUL control character instead — the value our harness read back as the literal text _x0000_. - FVSCHEDULE: LibreOffice drops text in the rate schedule
Microsoft documents any non-numeric value in FVSCHEDULE's schedule as #VALUE!. Executed, LibreOffice 25.8.7.3 returns 1.09 for =FVSCHEDULE(1,A1:A2) with A2 = "x" - a compounding period silently dropped - while Google Sheets returns #VALUE! as documented. - TRIM strips tabs and line breaks in Google Sheets but keeps them in Excel and LibreOffice
Executed evidence: =TRIM(CHAR(9)&"Hello") keeps the tab in Excel for the web and in all four LibreOffice builds, but Google Sheets strips it (and line feeds too). Non-breaking spaces survive TRIM everywhere. The portable fix, with dates and per-engine provenance.