Why does JSON decoding into a Go `any` mangle a 19-digit id, and how do you keep it exact?

## Where the digits go JSON has exactly one numeric type and no size limit in the grammar. Go has many. When you decode into a typed destination, your type resolves the ambiguity: an `int64` field means "parse this as an integer", a `float32` field means "parse this as a float". When you decode into an `any`, nothing resolves it, so the decoder falls back on `float64` for every number. A `float64` follows IEEE 754 binary64: one sign bit, eleven exponent bits and fifty-two stored mantissa bits, giving fifty-three bits of precision. Every integer up to 2^53 (about 9.007·10^15) is exactly representable; above that, the representable values thin out, and any integer between them is rounded to the nearest one. A typical 19-digit identifier lands well above that threshold, so its low digits are simply not stored. Nothing fails. The decode returns a nil error. Only when the value is printed, compared, or re-encoded does the difference show — often at a downstream system, days later. ## The typed fix The first answer is usually not an API call but a struct: ```go type Event struct { ID int64 `json:"id"` } ``` The decoder sees an integer kind and parses the literal as an integer, so all nineteen digits survive, and there is no floating-point step to lose them in. It also gets you error handling for free: a literal with a fractional part, or one too large for the field, yields an `*json.UnmarshalTypeError` naming the offending field instead of a rounded value. If the id is genuinely bigger than an `int64` — some systems use unsigned 64-bit ids — use `uint64`, and if it is bigger than that, the honest wire type is a string. ## The UseNumber fix For documents whose shape you do not know, there is a decoder mode: ```go dec := json.NewDecoder(strings.NewReader(body)) dec.UseNumber() var v any err := dec.Decode(&v) ``` With `UseNumber` set, numbers stored into interface values arrive as `json.Number` instead of `float64`. `json.Number` is defined as a named string type holding the literal exactly as it appeared in the input, and it offers three methods: - `String() string` — the original literal, unchanged - `Int64() (int64, error)` — parses it as a signed 64-bit integer, erroring if it has a fraction or overflows - `Float64() (float64, error)` — parses it as a float, with the same rounding you were avoiding, but now as your explicit choice The key property is that nothing is interpreted until you ask. A 19-digit id survives as text; you can compare it, log it, or write it back out verbatim, and you can call `Int64()` and handle the error where it is meaningful. Note that a value too large for `int64` makes `Int64()` return a range error — the number is preserved, but that particular accessor cannot represent it. ## The one API wrinkle `UseNumber` is a method on `*json.Decoder`, and there is no equivalent option on the plain `json.Unmarshal` function. If your input is already a byte slice, you wrap it — `json.NewDecoder(bytes.NewReader(data))` — and use the decoder. That is a small friction point people trip over when they try to "turn on" precise numbers for an existing `Unmarshal` call site. ## Round-tripping This matters most for code that decodes a document, changes one field and writes the rest back out. Through a plain `map[string]any`, every number in the document has been through `float64` by the time you re-encode, so large integers come back rounded and numeric formatting can change (`1.0` may reappear as `1`). With `UseNumber`, `json.Number` re-encodes as its literal text, so untouched numbers come back byte-identical. ## What to say in an interview Name the cause precisely — no Go type to aim at, so `float64`, 53 bits of mantissa — and then give both fixes with the tradeoff between them: a typed struct when you know the schema, because it is faster, self-documenting and validating; `UseNumber` when you genuinely do not, because it defers interpretation instead of destroying it. Mentioning that the failure is silent, and that you would look for it by printing `%T` and the value at the boundary rather than trusting the decode's nil error, is what separates a memorised answer from one that has been debugged.