JSON Validation Checklist Before Production Deployment

Valid JSON is not necessarily safe or suitable for production.

A payload can be syntactically correct while containing missing fields, unexpected properties, invalid dates, oversized arrays, unsafe URLs, duplicate identifiers, or values that violate business rules.

Use this checklist before deploying an API, webhook, configuration file, data import, or service that accepts JSON.

Quick Production Checklist

Before deployment, confirm that your system:

The remaining sections explain how to verify each item.

1. Reject Malformed JSON

The first layer is syntax validation. Use a standard JSON parser rather than regular expressions or custom string processing.

Valid JSON:

{
  "name": "John Doe",
  "email": "john@example.com",
  "active": true
}

Invalid JSON:

{
  "name": "John Doe"
  "email": "john@example.com"
}

The invalid example is missing a comma.

Also test:

Missing closing braces or brackets
Unquoted property names
Single-quoted strings
Trailing commas
Invalid escape sequences
Raw control characters
NaN and Infinity
JavaScript comments
Empty request bodies
Truncated requests

JSON has a stricter syntax than JavaScript object literals. Its core format and interoperability rules are defined in RFC 8259.⁠⁠

JavaScript example

function parseJson(input) {
  try {
    return {
      ok: true,
      value: JSON.parse(input)
    };
  } catch (error) {
    return {
      ok: false,
      error: error.message
    };
  }
}

PHP example

<?php

try {
    $data = json_decode(
        $input,
        true,
        512,
        JSON_THROW_ON_ERROR
    );
} catch (JsonException $exception) {
    // Return a controlled invalid-JSON response.
}

Parsing validates syntax. Schema and business validation happen afterward.

2. Verify the Media Type

For an API request containing JSON, require an appropriate media type:

Content-Type: application/json

A specialized API may use a vendor media type ending in +json:

Content-Type: application/vnd.example.order+json

Define how the server handles:

Missing Content-Type
Unsupported media types
Invalid character-set parameters
JSON sent as form data
Empty JSON bodies
Compressed request bodies

Do not silently interpret every arbitrary request body as JSON. A consistent media-type policy prevents ambiguous processing.

3. Set the Size Limit Before Parsing

Reject oversized requests as early as possible.

A request-size limit should exist at multiple layers:

CDN or edge proxy
Web server
API gateway
Application server
JSON parser or application code
Queue or message broker

The correct limit depends on the endpoint. A profile update may need only a few kilobytes, while a controlled batch-import endpoint may require more.

Do not give every endpoint the maximum size required by the largest upload workflow.

Large JSON payloads can consume:

Network bandwidth
Application memory
Parser CPU
Validation time
Log storage
Queue capacity

Use direct file uploads, object storage, multipart uploads, pagination, or streaming formats for large datasets.

4. Validate Against a Versioned Schema

Syntax validation answers:

Can this text be parsed as JSON?

Schema validation answers:

Does the parsed value have the expected structure?

A JSON Schema might look like this:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/schemas/customer-create.json",
  "title": "Create customer request",
  "type": "object",
  "required": [
    "name",
    "email",
    "active"
  ],
  "properties": {
    "name": {
      "type": "string",
      "minLength": 1,
      "maxLength": 100
    },
    "email": {
      "type": "string",
      "format": "email",
      "maxLength": 254
    },
    "active": {
      "type": "boolean"
    },
    "roles": {
      "type": "array",
      "maxItems": 10,
      "uniqueItems": true,
      "items": {
        "type": "string",
        "enum": [
          "editor",
          "reviewer"
        ]
      }
    }
  },
  "additionalProperties": false
}

JSON Schema provides keywords for types, required properties, ranges, arrays, composition, and other structural constraints.⁠⁠

Schema checklist

Some validators treat formats such as email as annotations unless format assertions are enabled. Test the behavior of your selected library rather than assuming every keyword is enforced identically.

5. Define the Unknown-Property Policy

Consider this request:

{
  "name": "John",
  "email": "john@example.com",
  "isAdministrator": true
}

If isAdministrator is not part of the public contract, decide whether the API will:

Reject it
Ignore it
Store it
Pass it to another service

Rejecting unknown fields catches client mistakes and reduces mass-assignment risk:

{
  "additionalProperties": false
}

However, strict rejection can complicate compatibility when newer clients send fields to older services.

Choose deliberately based on the API’s versioning strategy. Never allow unknown input to be copied automatically into a database model.

6. Distinguish Missing, `null`, Empty, and Zero

These payloads are not equivalent:

{}

{
  "name": null
}

{
  "name": ""
}

{
  "name": " "
}

For numeric fields, these are also different:

{
  "quantity": 0
}

{
  "quantity": null
}

Define for every field:

Whether it is required
Whether null is accepted
Whether an empty string is accepted
Whether whitespace-only text is accepted
Whether zero is valid
Whether an empty array is valid
Whether omission means “leave unchanged” or “clear the value”

This is particularly important for PATCH requests. An omitted property often means “do not modify,” while an explicit null may mean “remove the value.”

7. Validate Strings Precisely

For each string field, consider:

Minimum length
Maximum length
Leading and trailing whitespace
Allowed characters
Case normalization
Line breaks
Unicode
Control characters
Canonical representation

Example:

{
  "username": {
    "type": "string",
    "minLength": 3,
    "maxLength": 30,
    "pattern": "^[a-z0-9_]+$"
  }
}

Use a restrictive regex only when the business requirement truly restricts the character set. Do not accidentally reject international names by applying an ASCII-only username rule to a person’s display name.

Avoid vague “sanitize everything” logic. Validation, normalization, escaping, and output encoding solve different problems.

8. Validate Numbers and Identifiers

Check:

Integer versus decimal requirements
Minimum and maximum values
Whether negative values are allowed
Decimal precision
Currency representation
Integer ranges supported by every consumer
Whether the value is actually an identifier

Large numeric identifiers can lose precision in JavaScript-based systems. Represent them as strings when arithmetic is unnecessary:

{
  "transactionId": "9223372036854775807"
}

For money, define whether the API uses:

Integer minor units
Decimal strings
A decimal data type
A currency object

Avoid binary floating-point arithmetic for financial totals without a deliberate precision strategy.

9. Validate Dates and Times

JSON does not have a native date type. Dates and timestamps are normally strings.

Example timestamp:

{
  "createdAt": "2026-09-28T06:30:35Z"
}

Date checklist:

A string matching a date pattern may still represent an impossible date. Parse it with a date library and apply business rules after structural validation.

10. Validate Arrays and Nested Objects

Do not validate only the array itself. Validate every item.

Example:

{
  "type": "array",
  "minItems": 1,
  "maxItems": 100,
  "uniqueItems": true,
  "items": {
    "type": "string",
    "maxLength": 50
  }
}

Nested-data checklist:

An array containing 100,000 individually valid objects can still exhaust application resources.

11. Check Duplicate Property Names

This payload contains two role properties:

{
  "role": "user",
  "role": "administrator"
}

The JSON specification recommends unique names within an object because parsers handle duplicates differently. Some retain the final value, some reject the document, and others expose every occurrence.⁠⁠

If the parser exposes duplicate-key detection, enable it for security-sensitive inputs.

At minimum:

Test your parser’s duplicate-key behavior.
Ensure upstream and downstream systems interpret duplicates consistently.
Do not sign, validate, and process the same payload using parsers with conflicting behavior.

12. Apply Business Rules Separately

A schema can confirm that startDate and endDate are strings, but application logic must confirm that the dates form an acceptable range:

{
  "startDate": "2026-10-10",
  "endDate": "2026-10-01"
}

Typical business rules include:

End date must follow start date
Product must exist
Account must be active
Requested quantity must be available
Coupon must not have expired
User must have permission
Identifier must belong to the current tenant
Status transition must be allowed
Related records must be compatible

Use this order:

Parse JSON
Validate structure
Authenticate the caller
Authorize the operation
Apply business rules
Perform the operation safely

Valid JSON never grants authorization.

13. Prevent Mass Assignment

Do not pass an entire request object directly into a database update.

Risky example:

$user->update($request->all());

If the model or framework configuration is permissive, the client may modify properties that were never intended to be public.

Use validated, explicitly approved fields:

$validated = $request->validate([
    'name' => ['required', 'string', 'max:100'],
    'email' => ['required', 'email', 'max:254'],
]);

$user->update($validated);

Authorization-sensitive properties should be handled through separate operations:

$user->update([
    'name' => $validated['name'],
    'email' => $validated['email'],
]);

Object-property authorization and unrestricted property binding are recognized API security concerns by OWASP.⁠⁠

14. Protect Against Resource Exhaustion

Set limits for:

Request bytes
Decompressed bytes
Object depth
Number of properties
Array length
String length
Numeric size
Regex execution
Schema-reference resolution
Validation time
Concurrent validation requests
Batch size

Also consider compressed request bodies. A small compressed body can expand into a much larger value after decompression.

OWASP identifies unrestricted resource consumption as a major API risk.⁠⁠

Reject excessive input before performing expensive database lookups or external API calls.

15. Do Not Treat Sanitization as a Universal Fix

There is no single “sanitize JSON” function that makes every value safe.

Apply protection at the point where data is used:

Parameterized queries for SQL
Output encoding for HTML
Safe process APIs for operating-system commands
URL validation for outbound requests
Context-aware escaping for templates
Path restrictions for file operations
Allowlisted fields for model updates

Modifying input prematurely can corrupt legitimate data while failing to prevent context-specific attacks.

16. Return Consistent Validation Errors

A response such as this is difficult for clients to use:

{
  "error": "Invalid"
}

A better response identifies the category and affected field:

{
  "type": "https://api.example.com/problems/validation-error",
  "title": "Request validation failed",
  "status": 422,
  "errors": [
    {
      "pointer": "#/email",
      "detail": "The email field is required."
    },
    {
      "pointer": "#/roles",
      "detail": "No more than 10 roles are allowed."
    }
  ]
}

RFC 9457 defines a standard Problem Details format for machine-readable HTTP API errors.⁠⁠

Error-response checklist:

Use 400 Bad Request for malformed request syntax or according to your API policy. Many APIs use 422 Unprocessable Content for structurally parseable content that fails application validation. Consistency matters more than switching status codes unpredictably.

17. Test Compatibility Before Deployment

A schema change can break consumers even when the new payload is valid.

Potentially breaking changes include:

Removing a field
Renaming a field
Changing a type
Making an optional field required
Tightening a range
Removing an enum value
Changing null behavior
Changing date formats
Rejecting previously accepted properties

Adding a property can also break consumers that reject unknown fields.

Compatibility checklist:

Use consumer-driven contract tests when several independently deployed services share JSON contracts.

18. Test Unicode and Encoding

JSON exchanged between separate systems should use UTF-8 for interoperability.⁠⁠

Test values containing:

{
  "english": "Hello",
  "urdu": "خوش آمدید",
  "arabic": "مرحبا",
  "emoji": "👋",
  "accented": "café"
}

Also test:

Combining characters
Right-to-left text
Emoji with multiple code points
Escaped Unicode sequences
Control characters
Invalid byte sequences
String-length behavior

A user-visible character does not always equal one byte, one code point, or one JavaScript string unit. Define whether length limits are measured in bytes, code points, or user-perceived characters.

19. Protect Logs and Monitoring

Validation errors are useful operational signals, but complete payload logging can expose secrets.

Do not log:

Passwords
Access tokens
API keys
Session cookies
Payment information
Private keys
Complete personal records

Prefer structured metadata:

{
  "event": "json_validation_failed",
  "endpoint": "/api/customers",
  "schemaVersion": "2.1",
  "errorCode": "required_property_missing",
  "field": "email",
  "requestId": "req_123"
}

Track:

Validation-failure rate
Failure reason
Endpoint
Client or integration
Schema version
Payload-size distribution
Validation latency
Rejected unknown properties

A sudden increase after deployment can reveal a compatibility problem.

20. Automate Validation in CI

Store schemas, fixtures, and contract tests in version control.

Example project structure:

schemas/
  customer-create.schema.json
  customer-response.schema.json

fixtures/
  valid/
    customer-minimal.json
    customer-complete.json

  invalid/
    customer-missing-email.json
    customer-extra-property.json
    customer-oversized-roles.json

A CI job should:

Validate that every schema is itself valid.
Confirm valid fixtures pass.
Confirm invalid fixtures fail for the expected reason.
Compare schemas for breaking changes.
Run producer and consumer contract tests.
Test representative large inputs.
Report failures before deployment.

Basic syntax check with `jq`

jq empty fixtures/valid/customer-minimal.json

Format a file:

jq . input.json

Minify it:

jq -c . input.json

jq confirms JSON syntax but does not automatically validate application-specific schema rules.

Basic syntax check with Python

python -m json.tool input.json > /dev/null

Use a JSON Schema validator for structural checks.

21. Load-Test the Validation Layer

Measure validation with realistic payloads, not only one minimal example.

Test:

Normal payloads
Maximum accepted payloads
Deeply nested payloads
Large arrays
Many concurrent invalid requests
Repeated schema failures
Slow business-rule lookups
Compressed requests
Error-response generation

Record:

Median and percentile latency
CPU time
Peak memory
Request throughput
Error rate
Log volume
Downstream database calls

Invalid requests should fail early. They should not trigger expensive database or external-service operations unnecessarily.

22. Prepare Deployment and Rollback

Before release:

After release:

Monitor validation-error rates.
Compare errors by client version.
Check payload-size and latency metrics.
Look for rejected unknown fields.
Review third-party integration failures.
Confirm that sensitive input is not entering logs.

Copyable Final Checklist

Parsing and Transport

Correct JSON media type required
Malformed JSON rejected
Empty-body behavior defined
UTF-8 behavior tested
Request-size limits enforced before parsing

Schema

Schema draft declared
Root type declared
Required fields defined
Unknown-property policy defined
String and array lengths bounded
Numeric ranges bounded
Enums documented
Nested objects validated
Schema stored in version control

Application Rules

Missing values and null handled separately
Dates parsed semantically
Cross-field rules tested
Identifiers checked against the current user or tenant
Authorization performed
Mass assignment prevented

Security

Nesting and collection limits exist
Expensive validation is bounded
SQL uses parameters
HTML output is encoded
Outbound URLs are restricted
Secrets are removed from logs
Duplicate-key behavior is known

API Behavior

Error format is consistent
Status-code policy is documented
Error messages identify invalid fields
Internal details are hidden
Request IDs are returned or logged

Delivery

Valid and invalid fixtures exist
Contract tests run in CI
Breaking schema changes are detected
Older clients are tested
Validation is load-tested
Monitoring and rollback are ready

Final Thoughts

Production JSON validation is not one parser call.

A reliable system validates several independent concerns:

Transport: Is the request type and size acceptable?
Syntax: Can the JSON be parsed?
Structure: Does it match the documented contract?
Semantics: Are the values meaningful?
Authorization: May this caller perform the requested action?
Security: Can the payload exhaust resources or modify protected properties?
Compatibility: Will existing producers and consumers continue to work?
Operations: Can failures be detected without exposing sensitive data?

Treat the schema, fixtures, tests, limits, error format, and monitoring configuration as deployable application components. That approach turns JSON validation from an informal manual check into a repeatable production control.