I thought I was making my life easy and being future-conscious by saving some content as bits of JSON in custom post_meta fields. Unfortunately, WordPress doesn't agree and is making my life incredibly difficult.

I have a JSON string that looks essentially like this. This is just one bit, and the comment string is just some dummy unicode entities. The whole thing is generated w/ json_encode.

    "0": {
        "name": "Chris",
        "url": "testdomain.com",
        "comment": "\u00a5 \u00b7 \u00a3 \u00b7 \u20ac \u00b7 \u00b7 \u00a2 \u00b7 \u20a1 \u00b7 \u20a2 \u00b7 \u20a3 \u00b7 \u20a4 \u00b7 \u20a5 \u00b7 \u20a6 \u00b7 \u20a7 \u00b7 \u20a8 \u00b7 \u20a9 \u00b7 \u20aa \u00b7 \u20ab \u00b7 \u20ad \u00b7 \u20ae \u00b7 \u20af \u00b7 \u20b9"

Unfortunately after I save it with update_post_meta, it comes out looking like this:

    "0": {
        "name": "Chris",
        "url": "testdomain.com",
        "comment": "u00a5 u00b7 u00a3 u00b7 u20ac u00b7 u00b7 u00a2 u00b7 u20a1 u00b7 u20a2 u00b7 u20a3 u00b7 u20a4 u00b7 u20a5 u00b7 u20a6 u00b7 u20a7 u00b7 u20a8 u00b7 u20a9 u00b7 u20aa u00b7 u20ab u00b7 u20ad u00b7 u20ae u00b7 u20af u00b7 u20b9"

And with the slashes stripped, it can't be json_decoded back into useful content.

Any ideas why WordPress might be doing this, and if there is a way to avoid it? I can't use the JSON_UNESCAPED_UNICODE flag because this is a PHP 5.3.x install, and I've already tried encoding with htmlentities before the content is passed to json_encode, but that only captures a small subset of UTF-8 entities.

Thanks in advance!

(EDIT: FWIW, I know I could just save an array directly to post_meta and it'd be serialized and magic would happen but I just like the idea of having the data stored as JSON. If there isn't an easy, elegant solution I'll cave, but I'm very much hoping there is an easy, elegant solution!)

8 Answers 8


Doesn't look like there's any way to avoid it.

The update_metadata() function, which is ultimately responsible for saving the meta, explicitly runs a stripslashes_deep() on the meta value. This function will even strip slashes from array elements, if the value were an array.

Theres a filter that's run AFTER that called sanitize_meta, which you could hook in to. But at that point, your slashes have already been stripped, so you can't reliably determine where they needed to be added back in (or at least, I don't know how you would tell the difference between quoting legitimate JSON delimiters vs bits of values).

Can't speak to why it does this, but it does. Probably because it's eventually run through wpdb->update, which needs the strings unescaped.

As you feared, you're probably better off just storing the value as an array, which'll get serialized (as you said). If you want it as JSON later, you can just run it through json_encode().

  • I was afraid of that, but it's good to know why it's happening. Thanks so much for the quick response! May 25, 2012 at 21:33
  • 1
    This is nor true, see other answers :)
    – jave.web
    Mar 6, 2015 at 14:51
  • 1
    @jave.web It is true that you can't avoid having update_metadata() run strip slashes on your string. The other answers provide (very smart) workarounds to essentially "double escape" your string, so that the unavoidable stripping removes those extra slashes but leaves your original slashes intact. I'd personally still say that the "elegant" way to handle this is to just store data in an array, which requires no special handling or pre-formatting. Then convert it to json if and when you need to. But that's just my preference.
    – MathSmath
    May 6, 2015 at 18:36

There is an elegant way to handle this!

Pass the JSON encoded string through wp_slash(). That function will escape the leading slash of each encoded unicode character, which will prevent update_metadata() from stripping them.

  • This is a workaround for a serious Wordpress bug. Thanks a lot!
    – netAction
    Jun 7, 2017 at 7:18
  • 2
    This should be the accepted answer. I had issues with content being imported from GitHub through wp_insert_post where this was a major issue removing slashes from code samples. Running the string through wp_slash before sending it through wp_insert_post did the trick. Thanks!
    – Matt Keys
    Nov 17, 2017 at 19:21
  • This is still being useful even today, I lost hours and hours to find a workaround for this without a single clue until I found this. If you want to add this response on my question here: stackoverflow.com/questions/61091853/… I will mark it as the correct answer. Thank you so much!
    – Jaypee
    Apr 8, 2020 at 4:02
  • Who'd have thought that an 8 year old post could help me out. I was having problems saving serialized (Gutenberg) blocks, with JSON encoded attributes that was having their slashes removed. Running the output of serialize_block through wp_slash did the trick. Apr 5, 2021 at 13:47

You can cheat to wordpress with something like this:

$cleandata = str_replace('\\', '\\\\', json_encode($customfield_data, true));

This is that easy *elegant solution*...

  • +1 This did the trick for my situation. it was a little different than the OP, but similar. Aug 1, 2018 at 11:43

This function does the transformation using preg_replace:

function preg_replace_add_slash_json($value) {
    return preg_replace('/(u[0-9a-fA-F]{4})/i', '\\\$1', $value);

Before each "uXXXX" (X=0..F, hexadecimal) sequence it adds backslash. Before submitting to DB, call this function.


For anyone still struggling with saving a json encoded unicode string via wp_update_post, the following worked for me. Found in class-wp-rest-posts-controller.php

// convert the post object to an array, otherwise wp_update_post will expect non-escaped input.
wp_update_post( wp_slash( (array) $my_post ) ); 

Here's an example:

$objectToEncodeToJson = array(
  'my_custom_key' => '<div>Here is HTML that will be converted to Unicode in the db.</div>'

$postContent = json_encode($objectToEncodeToJson,JSON_HEX_TAG|JSON_HEX_QUOT);

$my_post = array(
  'ID'           => $yourPostId,
  'post_content' => $postContent

wp_update_post( wp_slash( (array) $my_post ) );

An interest way around this is to encode to base64 see example below.

$data = Array(0 => array('name' => 'chris' , 'URL' => "hello.com"));

$to_json = json_encode($data);

echo $to_json  . "<br />";
//echos [{"name":"chris","URL":"hello.com"}] 

$to_base64 =  base64_encode($to_json);

Echo $to_base64 . "<br />";
//echos W3sibmFtZSI6ImNocmlzIiwiVVJMIjoiaGVsbG8uY29tIn1d

$back_to_json =  base64_decode($to_base64);

Echo $back_to_json . "<br />";
//echos [{"name":"chris","URL":"hello.com"}]

$back_to_aray = json_decode($back_to_json);

print_r($back_to_aray) ;
//echos  Array ( [0] => stdClass Object ( [name] => chris [URL] => hello.com ))

I know this is an old question, but it's still an issue impacting developers today. So as a reference, here's a good thread from the wordpress core issues tracker that I found informative: https://core.trac.wordpress.org/ticket/21767

New contributor
jvp is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

You can use the WordPress stripslashes_deep() function.

<?php stripslashes_deep($your_json);?>

For reference visit here

  • BARBJANE's is still sent from WordPress as BARBJANE\'s unless I am missing something here...
    – Si8
    Apr 10, 2018 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.