Validador JSON

What is JSON Validation?

JSON validation is the process of checking whether a text string conforms to the JSON grammar defined by RFC 8259. Unlike formatting — which reorganizes whitespace for readability — validation answers a binary question: is this input valid JSON or not? When the input is invalid, a good validator reports the exact location and nature of the error so you can fix it quickly. This tool parses your input against the strict JSON specification and provides detailed error diagnostics including line numbers, column positions, and suggestions for common mistakes that cause parsing failures.

JSON Syntax Rules: What Makes Valid JSON

The JSON specification (RFC 8259) defines a surprisingly strict grammar compared to JavaScript object literals. Many developers write JSON by hand assuming JavaScript-like flexibility, only to encounter parsing errors. Understanding these rules prevents frustrating debugging sessions:

• Strings must use double quotes: Single quotes ('hello') and backtick template literals are JavaScript syntax, not JSON. Every string — including object keys — must be wrapped in double quotes ("hello").
• No trailing commas: A comma after the last element in an array ([1, 2, 3,]) or the last property in an object ({"a": 1,}) is invalid JSON, even though JavaScript allows it.
• No comments: JSON has no comment syntax. Neither // line comments nor /* */ block comments are valid. Use JSON5 or JSONC if you need comments in configuration files.
• No undefined, NaN, or Infinity: These JavaScript values have no JSON representation. Use null for absent values. Numbers must be finite — use string representations like "NaN" or "Infinity" if your application requires them.
• Object keys must be strings: Unquoted keys ({name: "value"}) are invalid. Every key must be a double-quoted string ({"name": "value"}).
• No hexadecimal or octal numbers: Numbers must be decimal. Use 255 instead of 0xFF.

The valid JSON data types are: string, number, boolean (true/false), null, object (unordered key-value collection), and array (ordered list). A valid JSON document must have exactly one top-level value — typically an object or array, though the specification technically allows any value type at the root level.

Common Validation Errors and How to Fix Them

When JSON validation fails, the error message points to where the parser encountered unexpected input. Here are the most frequent causes of validation failures and their solutions:

Unexpected token at position N: This generic error means the parser found a character it did not expect at that position. Common culprits include: a trailing comma before a closing bracket, a single-quoted string, an unquoted key, or a JavaScript expression like a function call. The position number counts bytes from the start of the document — use this tool's line and column reporting to locate the exact spot.

Unexpected end of JSON input: The document ended before the parser finished reading a value. This typically means a missing closing brace }, bracket ], or quote ". Check that every opening delimiter has a matching close, especially in deeply nested structures.

Bad control character in string: JSON strings cannot contain unescaped control characters (codepoints U+0000 through U+001F). Tabs must be escaped as \t, newlines as \n, and carriage returns as \r. Copy-pasting from terminals or editors sometimes introduces invisible control characters.

Duplicate keys: While RFC 8259 does not strictly forbid duplicate keys in an object, it states that implementations should avoid them and behavior is undefined. Most parsers silently accept the last value, which can mask bugs. This validator flags duplicate keys as warnings because they indicate likely errors in hand-written JSON.

Validation vs Formatting: When to Use Which

JSON validation and JSON formatting serve different purposes in a developer workflow. Validation tells you whether a document is syntactically correct — it answers "can this be parsed?" with a yes/no result plus error details. Formatting takes already-valid JSON and makes it readable by adding indentation and line breaks, or minifies it by removing whitespace. Formatting inherently validates (because it must parse the input first), but validation does not format.

Use this validator when you need to quickly check if JSON from an external source — an API response copied from a log file, a configuration snippet from documentation, or data pasted from a colleague — is syntactically correct before processing it further. The validator gives you precise error locations and actionable suggestions rather than just a formatted or unchanged output.

In CI/CD pipelines, JSON validation is a gate: configuration files, API contract schemas, and translation bundles are validated before deployment to catch syntax errors early. Schema validation (using JSON Schema) goes further by checking that values match expected types and constraints, but syntactic validation is always the first step — a document with invalid syntax cannot be schema-validated at all.

RFC 8259: The JSON Specification

RFC 8259, published in December 2017 by the IETF, is the current and definitive specification for JSON (JavaScript Object Notation). It supersedes RFC 7159 (2014) and the original RFC 4627 (2006). The specification defines JSON as a lightweight, text-based data interchange format that is language-independent but uses conventions familiar to C-family programmers.

Key points from RFC 8259 that affect validation: the specification mandates UTF-8 encoding for JSON transmitted over networks (Section 8.1), allows any JSON value as a top-level element (not just objects and arrays as in the original RFC 4627), and requires that parsers accept all valid JSON texts while rejecting those with syntax errors. The specification deliberately leaves some behaviors implementation-defined — for example, the maximum nesting depth and the precision of number parsing — which is why different parsers may accept slightly different inputs.

ECMA-404, published by Ecma International, is a companion standard that defines the same grammar in a more formal notation. The two specifications are maintained in alignment and describe identical syntax rules. For practical purposes, they are interchangeable references.

Code Examples

Validating JSON in JavaScript with detailed error reporting

function validateJson(input) {
  try {
    JSON.parse(input);
    return { valid: true };
  } catch (error) {
    // Extract position from error message
    const match = error.message.match(/position (\d+)/);
    const position = match ? parseInt(match[1], 10) : null;

    // Calculate line and column from position
    let line = 1, column = 1;
    if (position !== null) {
      for (let i = 0; i < position && i < input.length; i++) {
        if (input[i] === '\n') { line++; column = 1; }
        else { column++; }
      }
    }

    return {
      valid: false,
      error: error.message,
      line,
      column,
      position
    };
  }
}

// Examples of invalid JSON:
validateJson('{"name": "Alice",}');
// → { valid: false, error: "...unexpected...", line: 1, column: 18 }

validateJson('{"valid": true}');
// → { valid: true }

Common JSON mistakes that fail validation

// ❌ Trailing comma (invalid)
{"items": [1, 2, 3,]}

// ❌ Single quotes (invalid)
{'name': 'Alice'}

// ❌ Unquoted keys (invalid)
{name: "Alice"}

// ❌ NaN / Infinity (invalid)
{"value": NaN, "max": Infinity}

// ❌ Comments (invalid)
{
  // This is a config file
  "debug": true
}

// ✅ Correct JSON
{
  "name": "Alice",
  "age": 30,
  "active": true,
  "scores": [98, 87, 92],
  "address": null
}

Standards & Specifications

• RFC 8259 — The current JSON specification (2017) defining the grammar rules this validator enforces
• ECMA-404 — ECMA standard for JSON Data Interchange Syntax — formally equivalent to RFC 8259