google/gson · error · NumberFormatException

Number string too large: {value}...

Error message

Number string too large: {value}...

What it means

Thrown by NumberLimits.checkNumberStringLength as NumberFormatException when a number string parsed from JSON exceeds 10,000 characters. This is a DoS defence: extremely long number literals can be expensive or destabilizing to parse into BigDecimal/BigInteger, so Gson caps the input length and rejects oversized numeric tokens early.

Source

Thrown at gson/src/main/java/com/google/gson/internal/NumberLimits.java:17

package com.google.gson.internal;

import java.math.BigDecimal;
import java.math.BigInteger;

/**
 * This class enforces limits on numbers parsed from JSON to avoid potential performance problems
 * when extremely large numbers are used.
 */
public final class NumberLimits {
  private NumberLimits() {}

  private static final int MAX_NUMBER_STRING_LENGTH = 10_000;

  private static void checkNumberStringLength(String s) {
    if (s.length() > MAX_NUMBER_STRING_LENGTH) {
      throw new NumberFormatException("Number string too large: " + s.substring(0, 30) + "...");
    }
  }

  public static BigDecimal parseBigDecimal(String s) throws NumberFormatException {
    checkNumberStringLength(s);
    BigDecimal decimal = new BigDecimal(s);

    // Cast to long to avoid issues with abs when value is Integer.MIN_VALUE
    if (Math.abs((long) decimal.scale()) >= 10_000) {
      throw new NumberFormatException("Number has unsupported scale: " + s);
    }
    return decimal;
  }

  public static BigInteger parseBigInteger(String s) throws NumberFormatException {
    checkNumberStringLength(s);
    return new BigInteger(s);
  }

View on GitHub (pinned to 8b8628c656)

Solutions

1. Validate/normalize input upstream: reject or treat excessively long number literals as strings before parsing.
2. If you control the schema, model the field as a JSON string rather than a number and parse it yourself with bounded precision.
3. Configure stream limits / content-length caps at the HTTP layer to reject oversized payloads early.

Example fix

// before: unbounded numeric input
gson.fromJson(hugeJson, BigDecimal.class); // NumberFormatException

// after: read as string, then validate length
String numStr = gson.fromJson(hugeJson, String.class);
if (numStr.length() > 10_000) throw new IllegalArgumentException("too large");
BigDecimal v = NumberLimits.parseBigDecimal(numStr);

static void checkNumberLen(String s) {
  if (s != null && s.length() > 10_000) {
    throw new IllegalArgumentException("Number literal exceeds 10,000 characters");
  }
}
// usage: checkNumberLen(numStr);

static boolean isAcceptableNumberLength(String s) {
  return s != null && s.length() <= 10_000;
}

try {
  gson.fromJson(json, BigDecimal.class);
} catch (NumberFormatException e) {
  if (e.getMessage().contains("too large")) {
    // read as String and reject, or truncate with policy
    throw new IllegalArgumentException("Payload rejected: oversized number", e);
  } else throw e;
}

When it happens

Trigger: Parsing a JSON document whose numeric value literal (the raw text between delimiters) is longer than 10,000 characters. Fires via LazilyParsedNumber.asBigDecimal()/NumberLimits.parseBigDecimal or parseBigInteger when the JSON reader hands on a very long number token.

Common situations: Untrusted JSON payloads containing pathological numbers (e.g. a single number with tens of thousands of digits); base64-or-hex-encoded blobs mis-typed as JSON numbers; adversarial/fuzzed input designed to exhaust CPU or memory.

Related errors

• Number has unsupported scale: {s}
• Deserialization is unsupported
• Invalid bitset value " + intValue + ", expected 0 or 1; at p
• Lossy conversion from " + intValue + " to byte; at path " +
• Lossy conversion from " + intValue + " to short; at path " +

AI-assisted analysis of google/gson@8b8628c656 (2026-08-04). Data as JSON: /data/errors/dc3327f403c6a24d.json. Report an issue: GitHub.