WordPress wp_json_encode Example: Pass Structured Data Safely
A production-focused look at exporting structured PHP data safely into JavaScript and inline config with wp_json_encode.
Published
May 6, 2026
Reading Time
2 min read
Updated
May 6, 2026

Implementation Notes
Extension points, code paths, and implementation choices that should survive contact with production.
Best For
WordPress developers, agencies, and technical teams building custom plugin or theme functionality with cleaner operational defaults.
Primary Topics
Editorial Focus
Build Pattern: Extension points, code paths, and implementation choices that should survive contact with production. Updated on May 6, 2026.
Full Report
Last reviewed: May 6, 2026
Passing structured data from PHP into JavaScript or an inline response often fails in subtle ways when code uses plain json_encode() out of habit. wp_json_encode() exists because WordPress wants stronger confidence checks around JSON output and a safer default helper for core-style integrations.
This guide shows where wp_json_encode() belongs in WordPress plugin and theme code and why it is the better default when structured data is leaving PHP.
Encode structured values before embedding them in a script
<?php
$config = array(
'apiRoot' => esc_url_raw( rest_url( 'vulnwp/v1/' ) ),
'nonce' => wp_create_nonce( 'wp_rest' ),
);
wp_add_inline_script(
'vulnwp-dashboard',
'window.vulnwpConfig = ' . wp_json_encode( $config ) . ';',
'before'
);
This is the reliable pattern when the browser needs a structured object, not a string assembled by hand.
Prefer it over raw json_encode() in WordPress code
The code reference notes that wp_json_encode() performs additional confidence handling if the underlying JSON encoding fails at first. That makes it a better default in WordPress environments where mixed content and legacy data can appear unexpectedly.
Still validate and escape inputs before encoding them
JSON encoding is not a substitute for sanitization. URLs, nonces, labels, and dynamic content should already be normalized before they are placed into the array that gets encoded.
Keep structured data contracts small
When PHP exports data to a script, the most maintainable payload is the smallest one that solves the real use case. Large configuration objects tend to grow stale and harder to audit.
Common mistakes
- Using raw string concatenation to build JavaScript objects. This is brittle and error-prone.
- Assuming JSON encoding sanitizes the values. Inputs still need the right preparation first.
- Sending far more data than the script needs. Smaller contracts age better.
- Choosing
json_encode()by habit. In WordPress code,wp_json_encode()is the better default.
Production checklist
- Use
wp_json_encode()for structured JSON output in WordPress code. - Prepare and sanitize values before they are encoded.
- Keep client-side config payloads narrow.
- Prefer explicit arrays over manual JavaScript string assembly.
- Test the final output in the actual browser runtime.
Related reading
Pair this with the wp_localize_script guide when the payload crosses into JavaScript, and with the rest_url article when the exported object contains API roots.


