How does financial uppercase differ from ordinary Chinese numerals?

Financial documents use the complex forms 壹贰叁肆伍陆柒捌玖拾佰仟万亿 to prevent tampering: 1680 becomes 壹仟陆佰捌拾元整. The colloquial form is readable but alterable. Invoices and contracts require the financial form; the tool outputs both.

How do 万 and 亿 group digits?

Chinese groups every 4 digits: 个、万、亿、兆. 100,000,000 is 一亿 — not "a hundred hundred-thousands". English groups every 3 (thousand, million, billion), and this mismatch is where Chinese-English amount translation most often goes wrong.

How are decimal amounts written?

In RMB the first decimal place is 角 and the second 分: ¥1.23 is 壹元贰角叁分. With no jiao, write 零叁分; whole amounts end with 整 per financial convention.

Text Utilities

Number to Chinese Uppercase

Convert Arabic numbers to Chinese uppercase numbers, including currency style.

Input Number

🔢

Enter a number to start conversion

Converts Arabic numerals to Chinese uppercase numerals

Conversion Rules

Number Mode:

Supports integer conversion (0-999999999999999)
Uses 零/壹/贰/叁/肆/伍/陆/柒/捌/玖 for digits
Uses 拾/佰/仟/万/亿/兆 for units

Currency Mode:

Supports decimal amounts (up to 2 decimal places: jiao/fen)
Appends "元" (Yuan) after integer part; shows "零元" even when 0
Decimal part uses "角" (jiao) and "分" (fen)
Displays "整" (zheng) when there is no decimal part
Supports range: 0 - 999,999,999,999,999.99 (999 trillion)
Compliant with financial standards for invoices, contracts, checks

Examples:

Number：123456 → 壹拾贰万叁仟肆佰伍拾陆
Currency：1234.56 → 壹仟贰佰叁拾肆元伍角陆分
Currency：1000 → 壹仟元整
Currency：0.05 → 零元伍分
Currency：0.5 → 零元伍角
Currency：1000000 → 壹佰万元整

What is Number to Chinese Converter?

Converts Arabic numerals to Chinese characters, supporting both simplified and traditional Chinese, as well as financial (大写) format.

Features

Standard: 一、二、三...
Financial: 壹、贰、叁... (for checks)
Currency: Adds 元、角、分

Use Cases

Financial documents
Check writing
Legal documents

Rewrites Arabic numerals in Chinese financial uppercase — 零壹贰叁肆伍陆柒捌玖 combined with 仟, 佰, 拾 and 万/亿/兆 — in two modes: bare numbers, and RMB amounts closed with 元, 角, 分 and 整. It is meant for invoices, contracts, cheques and expense forms, where an amount must also appear in a form that resists alteration.

Four digits per group, and the 兆 ceiling

Chinese numerals group digits in fours from the right, not in threes. Each group of four is read with 仟, 佰, 拾 and the financial digits 壹 through 玖, and the groups are joined by 万 (10^4), 亿 (10^8) and 兆 (10^12). The unit table inside the converter holds exactly four entries, so 兆 is a hard ceiling: 1000000000000 returns 壹兆, 1000000000000000 returns 壹仟兆, and the widest input that still fits is 9999999999999998. Push it one higher and the number rounds up to 10^16 before grouping; a fifth group is then needed, the unit lookup comes back empty, and the word undefined lands inside the result — 9999999999999999 and 10000000000000000 both render as 壹undefined. 兆 is also ambiguous: as a metric prefix it means 10^6, while mainland invoice practice writes 万亿 rather than 兆.

When a 零 is written, and when the junction loses it

Every group is padded to four characters, so 1409 is read as 1-4-0-9 and comes out 壹仟肆佰零玖: a single 零 covers the zero digit sitting between two non-zero digits. A 零 is also emitted when a whole group is zero while a later group is not, which is why 100000001 gives 壹亿零壹 and 1000000001 gives 壹拾亿零壹. The junction between two non-zero groups is handled less carefully: when the following group is worth less than 1000 its leading zeros are trimmed and no joining 零 is added, so 10001 becomes 壹万壹 and 10500 becomes 壹万伍佰. Finally the routine collapses repeated 零 into one character and trims a trailing one, giving 陆仟零柒 for 6007 and 壹仟陆佰捌拾 for 1680.

Currency mode: 元, 角, 分 and 整

Currency mode appends 元 to the integer part — 零元 when that part is zero — pads the fraction to two digits so 0.5 and 0.50 behave alike, and writes 角 or 分 only for non-zero digits. 整 closes the string only when no fraction was entered: 1000 gives 壹仟元整, while 1409.50 gives 壹仟肆佰零玖元伍角 with no 整, which accounting practice allows once 角 is present. When 角 is zero but 分 is not, a 零 is inserted after 元, so 0.05 returns 零元零伍分 and 325.04 returns 叁佰贰拾伍元零肆分. A third decimal place is refused outright rather than rounded away.

Worked example

An invoice amount of 1,409.50 yuan

Input

1409.50

Output

壹仟肆佰零玖元伍角

Currency mode. The integer 1409 has a zero in the tens place, so one 零 separates 肆佰 from 玖, and 元 follows. The fraction 50 is padded to two digits: 角 is 5, 分 is 0, so only 伍角 is printed and no 整 is appended, because the input did carry a decimal part.

Limits and pitfalls

The unit table ends at 兆, so the answer breaks as soon as a fifth group is needed: 10000000000000000 gives 壹undefined, and so does 9999999999999999, which floating point rounds up to 10^16 before the grouping; the number-mode guard of 999999999999999999 lets both through.
Both modes print the financial forms 壹贰叁肆伍陆柒捌玖, so number mode never outputs 一二三; it also drops decimals without warning, and 12.9 converts as 壹拾贰.
Thousands separators are not stripped: parseFloat stops at the comma, so "1,234" is read as 1 and becomes 壹 in number mode, 壹元整 in currency mode.
Cents ride on binary floating point: 100000000000000.99 converts to 壹佰兆元玖角捌分, and the advertised maximum 999999999999999.99 rounds to 10^15 and returns 壹仟兆元整 with the 角分 gone.
Negative input is rejected with an error instead of being prefixed by 负, and the output never carries the 人民币 prefix that the 1997 rules for filling in bills and settlement vouchers require in front of a written amount.

Related tools

When it goes wrong

I typed 1e-3 into the amount box and it answered 零元整 — a thousandth of a yuan quietly became nothing.

CauseThe two-decimal guard reads the raw string with split('.'), and 1e-3 contains no dot, so the guard never fires. The value itself comes from num.toString(), which is 0.001; convertDecimal pads that to two places, slices to 00, returns an empty string, and the currency branch then appends 整.

FixType amounts as plain decimals: 0.001 is rejected outright with 金额最多支持两位小数. The same guard also misfires in the other direction — 1.9e15 is refused as a two-decimal problem, because the text after the dot is four characters long.

Our part numbers start with zeros: 007 comes back as 柒, and 0032 behaves exactly like 32.

CauseInput is parsed to a number before anything else, so leading zeros vanish at parseFloat, and convertInteger then derives the digit string from Math.floor(num).toString(). The original length is not carried anywhere in the pipeline, so no setting can bring the zeros back.

FixFor serials, convert digit by digit with an explicit map and preserve the source string; use this page only for quantities. If you must keep the value here, pad the zeros back manually after the copy, never before — a padding zero typed into the box would itself be stripped.

Pasting ¥1,234.56 copied from a web page, and full-width １２３４ copied from a PDF, both end in 请输入有效的数字.

CauseparseFloat accepts only an optional sign, ASCII digits, a dot and an exponent marker. A leading currency symbol makes the entire string NaN, and full-width digits (U+FF10 to U+FF19) are not digits to it. The NaN test runs after parsing, so the message blames the number instead of the characters.

FixRemove the symbol, switch the digits to half-width, and then paste 1234.56. A text-cleaning pass is faster than retyping a long amount, and it is the only reliable step — the box has no normalization of its own.

A slip of the finger left two dots in the box, 1409.5.0, and it answered 壹仟肆佰零玖元伍角 without a word of complaint.

CauseThe decimal guard inspects only split('.')[1], which is 5 — one character, so it passes — while parseFloat stops at the second dot and keeps 1409.5. Two different readers disagree about the string and neither one rejects it.

FixCheck the shape before trusting the answer: the regex /^[0-9]+(\.[0-9]{1,2})?$/ admits only a clean amount. When entering by hand, delete the extra dot and retype; when pasting a batch, run that regex over every line first.

Five jobs this page should not do for you

The job in front of you	This page (number to Chinese uppercase)	What to reach for instead
The value is an identifier that starts with zeros	Wrong tool. Everything goes through `parseFloat` before conversion, so `007` answers 柒 and `0032` is indistinguishable from 32. The converter rebuilds the digits from the parsed number, so the width you typed never reaches the output.	Map each character through 零壹贰叁肆伍陆柒捌玖 in a ten-line script and keep the string as typed. A serial number and an amount are two different readings, and only the amount belongs in a 万/亿/兆 grouping routine.
The amount sits in a database column as an integer number of fen	Paste `123456` and currency mode answers 壹拾贰万叁仟肆佰伍拾陆元整, a hundred times the real figure: every input is read as yuan, there is no fen switch, and even the five quick buttons run from 100 to 1,000,000 in yuan.	Divide by 100 first (or build the 元/角/分 string from the integer yourself) and paste `1234.56`. If the cents must stay exact past 15 digits, do the whole thing in your own code on integer fen, because this page converts through a JavaScript number.
A column of three hundred amounts, not one	One box, one answer, one copy button. Rows go in and come out one at a time, nothing loops over lines, and a skipped row looks exactly like a converted one.	Loop in Node or VBA over the column. Excel itself has no 元角分 uppercase function, so a formula column would need a custom function anyway, and a script leaves a diff you can read before the invoice goes out.
The reader wants it spoken: 一百二十三, not 壹佰贰拾叁	Both modes print the financial forms, because the digit table is fixed to 零壹贰叁肆伍陆柒捌玖. Switching to number mode changes the suffixes, never the characters.	A spoken reading is a different table (一二三四五六七八九 plus 十/百/千 and 两), so write that mapping yourself. Keep this page for the anti-alteration form that invoices and cheques actually demand.
The conversion has to run in CI or in a response body	This is a client-side page: no endpoint, no CLI, no export format, and the only way a value leaves it is the copy button on the result panel.	Install a library or keep the routine in the project. Ranges and rounding then follow your own rules instead of the guard constants baked into a form nobody can annotate.

Frequently Asked Questions

How does financial uppercase differ from ordinary Chinese numerals?: Financial documents use the complex forms 壹贰叁肆伍陆柒捌玖拾佰仟万亿 to prevent tampering: 1680 becomes 壹仟陆佰捌拾元整. The colloquial form is readable but alterable. Invoices and contracts require the financial form; the tool outputs both.
How do 万 and 亿 group digits?: Chinese groups every 4 digits: 个、万、亿、兆. 100,000,000 is 一亿 — not "a hundred hundred-thousands". English groups every 3 (thousand, million, billion), and this mismatch is where Chinese-English amount translation most often goes wrong.
How are decimal amounts written?: In RMB the first decimal place is 角 and the second 分: ¥1.23 is 壹元贰角叁分. With no jiao, write 零叁分; whole amounts end with 整 per financial convention.

Content reviewed: 2026-10-22