LENB
Quirk foundCategory: Text · Last tested 2026-09-01
Real compatibility results for the LENB 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-31) | Quirk found |
| LibreOffice Calc | Yes | Yes (25.8.7.3, 2026-08-31) | Quirk found |
LibreOffice version history
We executed the same test cases under each LibreOffice release to show exactly when LENB’s support changed — not documentation claims, real results.
| LibreOffice version | Verdict | Tested |
|---|---|---|
| 24.2.0.3 | Quirk found | 2026-08-31 |
| 24.8.7.2 | Quirk found | 2026-08-31 |
| 25.2.0.3 | Quirk found | 2026-08-31 |
| 25.8.7.3 | Quirk found | 2026-08-31 |
Why isn't LENB working in LibreOffice?
LENB 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.
Why isn’t LENB working in Google Sheets?
LENB runs in Google Sheets, but our executed cases show it does not match
Excel’s documented behavior on every input (the failing cases are listed on this page). If a
formula that behaves one way in Excel gives you a different answer in Sheets, compare your usage
against those cases before assuming your data is wrong.
Discovered quirks
-
=LENB("日本") on
Google Sheets returned
4, but the documented/expected
result is 2.
Provenance
Verbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case; MISMATCH vs expected: expected 2, got 4
-
=LENB("日本") on
LibreOffice Calc returned
4, but the documented/expected
result is 2.
Provenance
Verbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case; MISMATCH vs expected: expected 2, got 4
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 |
|---|---|---|---|---|
| =LENB("Phoenix, AZ") | Microsoft's documented example string: byte length of an 11-character ASCII string | 11 | 11ProvenanceMicrosoft's LEN/LENB page uses 'Phoenix, AZ' as its worked example and publishes LEN = 11. The DBCS rule (see the LENB_non_ascii_characters case) cannot change the answer here because every character is single-byte under either reading. NOTE: the current live page now states 'The LENB function is deprecated' and has dropped the DBCS explanation entirely |
Matched |
| =LENB("") | An empty string has zero bytes | 0 | 0ProvenanceNo characters means no bytes, under either the DBCS or the non-DBCS rule |
Matched |
| =LENB(" One ") | Spaces are characters and are counted, including leading and trailing ones | 8 | 8ProvenanceMicrosoft documents 'Spaces count as characters' for the text argument of LEN/LENB; the string here is two spaces, three letters and three spaces = 8 |
Matched |
| =LENB(1234) | A numeric argument is converted to its text representation before measuring | 4 | 4ProvenanceThe number 1234 becomes the four-character string "1234", so the byte length is 4 in a non-DBCS default language |
Matched |
| =LENB("日本") | DIVERGENCE PROBE: two CJK characters, where the byte count depends on the DBCS language rule | 2 | 2ProvenanceVerbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case |
Matched |
| =LENB(1/0) | An error argument propagates instead of being measured | #DIV/0! | #DIV/0!ProvenanceThe argument evaluates to #DIV/0! before LENB sees it, so the error is the result |
Matched |
Google Sheets (executed 2026-08-31 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 |
|---|---|---|---|---|
| =LENB("Phoenix, AZ") | Microsoft's documented example string: byte length of an 11-character ASCII string | 11 | 11ProvenanceMicrosoft's LEN/LENB page uses 'Phoenix, AZ' as its worked example and publishes LEN = 11. The DBCS rule (see the LENB_non_ascii_characters case) cannot change the answer here because every character is single-byte under either reading. NOTE: the current live page now states 'The LENB function is deprecated' and has dropped the DBCS explanation entirely |
Matched |
| =LENB("") | An empty string has zero bytes | 0 | 0ProvenanceNo characters means no bytes, under either the DBCS or the non-DBCS rule |
Matched |
| =LENB(" One ") | Spaces are characters and are counted, including leading and trailing ones | 8 | 8ProvenanceMicrosoft documents 'Spaces count as characters' for the text argument of LEN/LENB; the string here is two spaces, three letters and three spaces = 8 |
Matched |
| =LENB(1234) | A numeric argument is converted to its text representation before measuring | 4 | 4ProvenanceThe number 1234 becomes the four-character string "1234", so the byte length is 4 in a non-DBCS default language |
Matched |
| =LENB("日本") | DIVERGENCE PROBE: two CJK characters, where the byte count depends on the DBCS language rule | 4 | 2ProvenanceVerbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case |
Mismatch |
| =LENB(1/0) | An error argument propagates instead of being measured | #DIV/0! | #DIV/0!ProvenanceThe argument evaluates to #DIV/0! before LENB sees it, so the error is the result |
Matched |
LibreOffice Calc 25.8.7.3 (tested 2026-08-31)
| Formula | Description | Result | Expected | Verdict |
|---|---|---|---|---|
| =LENB("Phoenix, AZ") | Microsoft's documented example string: byte length of an 11-character ASCII string | 11 | 11ProvenanceMicrosoft's LEN/LENB page uses 'Phoenix, AZ' as its worked example and publishes LEN = 11. The DBCS rule (see the LENB_non_ascii_characters case) cannot change the answer here because every character is single-byte under either reading. NOTE: the current live page now states 'The LENB function is deprecated' and has dropped the DBCS explanation entirely |
Matched |
| =LENB("") | An empty string has zero bytes | 0 | 0ProvenanceNo characters means no bytes, under either the DBCS or the non-DBCS rule |
Matched |
| =LENB(" One ") | Spaces are characters and are counted, including leading and trailing ones | 8 | 8ProvenanceMicrosoft documents 'Spaces count as characters' for the text argument of LEN/LENB; the string here is two spaces, three letters and three spaces = 8 |
Matched |
| =LENB(1234) | A numeric argument is converted to its text representation before measuring | 4 | 4ProvenanceThe number 1234 becomes the four-character string "1234", so the byte length is 4 in a non-DBCS default language |
Matched |
| =LENB("日本") | DIVERGENCE PROBE: two CJK characters, where the byte count depends on the DBCS language rule | 4 | 2ProvenanceVerbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case |
Mismatch |
| =LENB(1/0) | An error argument propagates instead of being measured | #DIV/0! | #DIV/0!ProvenanceThe argument evaluates to #DIV/0! before LENB sees it, so the error is the result |
Matched |
Docs & syntax
- Excel (desktop): official documentation
- Google Sheets: official documentation
- LibreOffice Calc: official documentation
Where LENB behaves differently
- LENB and CJK text: 4 in Sheets and LibreOffice, 2 in Excel for the web
Microsoft's archived LEN/LENB page says LENB counts 2 bytes per character only under a DBCS default language, otherwise 1. Executed under a non-DBCS locale, =LENB("日本") returned 4 in Google Sheets and all four LibreOffice builds - but 2, the documented answer, in Excel for the web. Desktop Excel stays documentation only.