The Excel MIDB function extracts a substring starting at a given byte position, for a given number of bytes. It is the byte-counting twin of MID, built for double-byte character set (DBCS) languages — Japanese, Chinese, and Korean — where each native character occupies 2 bytes when such a language is the system default. Working in English or any other single-byte language? MIDB behaves exactly like MID — just use MID.
Syntax
| Argument | Description | |
|---|---|---|
text | Required | The string to extract from. |
start_num | Required | The byte position of the first byte to extract. The first byte of the string is 1. |
num_bytes | Required | How many bytes to return. Must be zero or positive. |
Available in: all Excel versions. Byte counting activates only when a DBCS language (Japanese, Chinese Simplified/Traditional, or Korean) is the system default language; otherwise every character counts as 1 byte and MIDB returns exactly what MID would. Pair it with FINDB, which reports positions in bytes.
MIDB vs MID: byte positions vs character positions
On a Japanese-locale system, 東京2026 lays out as 8 bytes — each kanji spans two byte positions. The year starts at byte 5 but character 3, which is why the same arguments return different slices:
| A | B | C | |
|---|---|---|---|
| 1 | Text in A2: 東京2026 | Formula | Result (Japanese locale) |
| 2 | byte positions: 東=1–2, 京=3–4, 2=5, 0=6, 2=7, 6=8 | =MIDB(A2, 5, 4) | 2026 |
| 3 | =MID(A2, 5, 4) | 26 | |
| 4 | =MIDB("Dallas", 2, 3) | all — same as MID |
Byte-defined field layouts are MIDB’s home turf. A legacy record with a 4-byte branch code at bytes 11–14 reads naturally:
Positions found with FINDB are byte positions — feed them to MIDB, never to MID:
Try it: char vs byte counter
Type text (mix in some kanji or kana), set start_num and num_bytes, and toggle the system locale to see byte positions in action.
Errors & common pitfalls
Pitfall: results depend on the system language, not the workbook. The same =MIDB(A2, 5, 4) slices different text on a Japanese-locale PC than on a US-locale one. When workbooks cross borders, byte-based extractions silently shift — document the locale assumption or avoid B functions in shared files.
Working in English? Use MID. On single-byte locales MIDB adds nothing. MID is portable and says what it means.
Pitfall: landing mid-character. If start_num or num_bytes splits a 2-byte character, the orphaned half becomes a space. =MIDB("東京", 2, 2) returns two spaces — half of each kanji. Always step through DBCS text in even byte counts, or anchor positions with FINDB.
#VALUE! — start_num < 1 or negative num_bytes. Both must be valid: start_num at least 1, num_bytes zero or more. Arithmetic on FINDB results is the usual source of an accidental 0 or negative.
Practice workbook
Frequently asked questions
What's the difference between MIDB and MID?
Why does MIDB give me the same answer as MID?
Can I mix MIDB with FIND, or MID with FINDB?
What happens if my byte range splits a double-byte character?
=MIDB("東京", 2, 2) returns " " — the second byte of 東 and the first byte of 京, both blanked. If you see mysterious spaces in extractions, your offsets are odd where they should be even.Master functions like this in one day
This page covers one function. Our Excel Formulas and Functions class covers the 30 that matter most — live, hands-on, taught by professionals in Dallas–Fort Worth, Houston, Austin, Oklahoma City, Denver, or online.
See the Formulas & Functions Class