Integer & float literals across languages
Same literal,
different number.
Type a numeric literal the way you’d write it in code — 017, 0xFF_EC, 1_000,
100L, 255u8, 1e3 — and see how C, Rust, Go, Java, Python and JavaScript
each read it: valid or not, the default type, the exact value, and where it overflows, loses precision, or
quietly means something else. It’s the cross-language picture, not a base converter.
Integer literal
“017” parses differently across languages — some reject it outright.
15
int (octal)
- Leading 0 means OCTAL in C.
17
i32 (default, if uninferred) (decimal)
- Leading zeros are allowed and mean DECIMAL in Rust (NOT octal) — use 0o for octal.
15
untyped int constant (octal)
- Leading 0 means OCTAL in Go (0o also works since Go 1.13).
- Untyped constant: arbitrary precision here, but overflows if assigned to a sized int (default int is 64-bit).
15
int (octal)
- Leading 0 means OCTAL in Java.
—
—
- leading zeros are NOT allowed in Python 3 — use the 0o prefix for octal (this is a SyntaxError)
15
number (legacy octal)
- Legacy octal: parsed as octal in sloppy mode, but a SyntaxError in strict mode and ES modules. Use 0o.
Integers are exact (BigInt); floats use IEEE-754 binary64; rules follow each language’s spec. Common literal forms are modelled — confirm exotic edge cases against the official reference. Computed in your browser, nothing uploaded. How it’s computed →
What it shows
The traps that bite when you copy a literal
Leading-zero octal
017 is octal 15 in C/Java/Go, decimal 17 in Rust, a SyntaxError in Python 3, and legacy-octal in sloppy-mode JS. One token, four meanings.
Separators: _ vs '
Underscores work in Rust/Go/Java/Python/JS; C and C++ use the apostrophe instead. Use the wrong one and it won’t compile.
Suffixes
100L (C/Java), 255u8 (Rust), 100n (JS BigInt), 1.5f (C/Java) — each exists in some languages and is a hard error in others.
Overflow & precision
Rust and Java reject out-of-range literals at compile time; C widens the type; Python is unbounded; JavaScript silently loses precision past 2^53 unless you add n.
Version gates
0b/0o/separators arrived in specific versions (Go 1.13, Java 7, ES6/ES2021, C23). The tool notes when a form needs a newer compiler.
Exact values
Integers are computed with BigInt — correct at any size — using each language’s own reading of the prefix. Floats use IEEE-754 binary64.
Open methodology
Exactly how each language is modelled
No black box — the rules follow each language’s own specification, so you can verify them.
- Base / prefix0x → hex, 0b → binary, 0o → explicit octal, a bare leading 0 → octal in C/Java/Go but DECIMAL in Rust and a SyntaxError in Python 3.
- Digit separatorsUnderscore in Rust, Go (1.13+), Java (7+), Python (3.6+) and JavaScript (ES2021); the apostrophe in C (C23) / C++ (C++14). Using the wrong one is an error in that language.
- Suffixesu/l/L (and combinations) in C; L only in Java; type tags i8…u128/f32/f64 in Rust; n for BigInt in JavaScript; f/d for floats in C/Java. Go and Python integers take NO suffix.
- ValueIntegers via BigInt (exact at any size). Floats via IEEE-754 binary64. The result for each language uses that language’s interpretation of the prefix.
- Overflow & precisionFixed-width types are range-checked (Rust/Java reject out-of-range literals at compile time; C widens the type). Python ints are unbounded. JavaScript numbers lose precision past 2^53−1 unless suffixed with n.
- Version gatesFeatures added in a specific version are noted: binary & 0o & separators in Go 1.13, binary & underscores in Java 7, 0b/0o in ES6 and separators in ES2021, binary & apostrophe separators in C23.
Honest scope: numlit models the common literal forms across C (C23), Rust, Go, Java, Python 3 and JavaScript. Integer values are exact (BigInt); floats use IEEE-754 binary64. Exotic forms — hexadecimal floats, every suffix permutation — are flagged rather than fully modelled. The rules follow each language’s specification (PEP 3127, the Go spec, the Rust reference, the C23 and Java language specs); confirm unusual edge cases against the official reference. It is not a base converter — it tells you what a compiler thinks your literal is.
Frequently asked questions
What does numlit do?
Type a numeric literal exactly as you would write it in source code — 0xFF_EC, 017, 1_000, 100L, 1e3, 255u8, 100n — and it shows how C, Rust, Go, Java, Python and JavaScript each read it: whether it is valid, the default type, the exact value, and where it overflows, loses precision, or means something surprising. It is the cross-language picture, not a base-2/8/16 conversion grid. Everything runs in your browser.
Why does the same literal differ between languages?
Each language has its own lexer rules for prefixes, leading zeros, digit separators and suffixes. The classic example is 017: it is octal 15 in C, Java and Go (leading zero = octal), but decimal 17 in Rust (leading zeros are allowed and stay decimal), a SyntaxError in Python 3, and a legacy octal that only works in sloppy-mode JavaScript. Copy a literal between languages and the value can silently change.
Which languages and forms are covered?
C (C23), Rust, Go, Java, Python 3 and JavaScript. It models the common literal forms: decimal, hex (0x), binary (0b) and octal (0o and leading-zero) integers; digit separators (underscore, and the apostrophe for C/C++); the standard suffixes (u/l/L, Rust type tags like u8/i64/f64, the JS n BigInt, Java f/d); and decimal floats with exponents. Exotic forms — hex floats, every suffix permutation — are flagged rather than fully modelled.
Are the values exact?
Integer values are computed with BigInt, so they are exact at any size. Floats use IEEE-754 binary64 (the same double most of these languages use), and the tool flags when a literal exceeds a type’s range (compile error), or — in JavaScript — exceeds 2^53−1 and loses precision unless you append n for a BigInt.
What traps does it catch?
Leading-zero octal (017), the missing 0o in C/Java, underscore vs apostrophe separators, suffixes that exist in one language and not another (100L, 255u8, 100n), binary/separator features gated behind a language version (Go 1.13, Java 7, ES6/ES2021, C23), integer overflow of fixed-width types, and JavaScript’s 2^53 precision cliff.
Is it a base converter?
No — that is the saturated tool this is deliberately not. If you just want decimal↔hex↔binary, any base converter does it. numlit answers a different question: "I wrote this exact literal — what does each language’s compiler think it is?"
Is it accurate and private?
The rules follow each language’s specification (e.g. PEP 3127 for Python, the Go spec, the Rust reference, the C23 and Java language specs); always confirm exotic edge cases against the official reference. It is a static page — every computation happens in your browser, nothing is uploaded, and there is no backend or logging.