In my little age with WordPress, I've seen WordPress itself and its friendly plugins are using PHP serialize() in storing data into db in many cases. But in a recent search I found a serious community support for the json_encode() over the serialize().

And I personally tested an associative array with both of 'em, that shows:

  • serialize() stores 342 chars
  • json_encode() stores 285 chars

Why I'm asking this?

I'm on a project while I'm going to store repeating meta fields to a post. Where:

  • Data would be basically in English, but sometimes can be Bengali
  • Data would be associative array, 3 level deep (I hope I understood levels correctly):
    1 => array(
    2 => array(

I've checked the postmeta table's meta_value field it's a longtext, that means a length of 4,294,967,295 chars (4GB).

So I need a robust solution into storing things.

up vote 13 down vote accepted

I think, not 100% sure that this was the real reason the WP developers took this approach, but common sense tells me that serialize preserves the variable types and have a mini built in error detection, and json stores only string values { key : value }, so when you go back to PHP you will have to guess the format, or make a parser for it. This will force you to have two different ways to handle your data: previous, to storing the data as json and after decoding the json it will come back as a totally different object.

This is the main reason the difference in size, PHP is storing not only an array; it is storing how many elements were in the array when it was serialized, their types, and their values.

You are not storing only key value pairs on the database but you may also be storing an object with different variable types.

  • I love the answer most. Really helpful points. – Mayeenul Islam Apr 7 '15 at 16:45
  • @MayeenulIslam Thanks! – Ramy Deeb Apr 8 '15 at 14:06
  • Atcutally what sounds as positive in this answer with the searialized data is only making it more complex (and insecure) than with a simpler serialization with JSON. Just saying. Actual reason is as given in the other answer that the time the feature was introduced, there was only the PHP serialize function, JSON was not yet there. – hakre Jun 18 '17 at 14:56

JSON encoding was introduced in PHP 5.2, WordPress is way older, and it was born (and designed for) PHP 4.

Data serialization is a pervasive thing in WordPress, so moving from PHP serialization to JSON encoding would mean a huge backward compatibility problem, and if I know WordPress a little, that will never happen.

That said, if you think that JSON encoding is better for you than PHP serialization, just use it.

If you pass a string (that is the JSON-encoded version of your data) to post meta functions WordPress will not touch it, but then you need to remember to JSON-decode data on retrieval.

If DB storage size is very important for you, that it probably worth the additional work, otherwise just let WordPress use what it uses and don't care about it.

Maybe, you can evaluate if it is the case of custom tables to save your data.

I am tempted to close this as "subject to opinion" but I think there are a couple of good answers to the question. I am going to go with "history".

1) json_encode is relatively new in PHP core.


(PHP 5 >= 5.2.0, PECL json >= 1.2.0) json_encode — Returns the JSON representation of a value

json_encode would not have been reliable in WordPress' early days. It was only rolled into "core" PHP in 5.2, though it was available as a PECL extension long before that.

Second, if you feed an object such as a WP_Query object into json_encode you get a stdClass object on json_decode. serialize/unserialize will preserve the object.

  • +1. But I object "subject to opinion", because I adjoined proofs. And the last one: class related issue: I already mentioned that on the second link (reasons why not json_encode). – Mayeenul Islam Apr 7 '15 at 16:51

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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