Integer & float literals across languages
Same literal, different number.
Type a numeric literal as 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: validity, default type, exact value, and overflow / precision / leading-zero traps. Not a base converter.
The traps that bite when you copy a literal
017 = octal 15 in C/Java/Go, decimal 17 in Rust, SyntaxError in Python 3, legacy-octal in sloppy JS.
Underscore in Rust/Go/Java/Python/JS; apostrophe in C/C++. The wrong one won’t compile.
100L, 255u8, 100n, 1.5f — each valid in some languages, an error in others.
Rust/Java reject out-of-range literals; C widens; Python is unbounded; JS loses precision past 2^53 unless you add n.
Why it matters
Each language’s lexer reads literals differently, so the same source text can be a different value — or a compile error — across languages. numlit applies each language’s spec with a disclosed method, computes integers exactly with BigInt, and runs entirely client-side so nothing you type is uploaded. It is deliberately not a base converter — it tells you what a compiler thinks your literal is. Common forms are modelled; confirm exotic edge cases against the official reference.
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.