I have a basic understanding of serialize (I come across it often when I'm migrating WordPress installs) and I just discovered json_encode.

Given that serialize causes so much trouble with replacing strings in the database (eg. editing an optinos field directly), why does WordPress prefer serialize to (the seemingly similar) json_encode, which doesn't insert the string length into the stored value.

My first thought was that it may provide some security or error-checking benefits - WordPress will ignore the option if the string lengths are incorrect.. but I'm interested in a qualified explanation :)

  • serialize representation can be stored in text and reversed
  • JSON representation can be stored in text but cannot always be precisely reversed

Run this example:

$query = new WP_Query();
var_dump( $query );
var_dump( unserialize( serialize( $query ) ) );
var_dump( json_decode( json_encode( $query ) ) );
  • After going through serialize accurate WP_Query object is re-created.
  • After going through JSON you get stdClass object.

In a nutshell serialize is native part of PHP and has a lot of synergy with manipulating data in it. JSON is language-agnostic format that is convenient for systems talking to each other, but far from comprehensive and cannot do things in PHP which serialize does without second thought.

  • I knew there had to be a good reason :) thanks @rarst
    – ptim
    Aug 8 '12 at 1:04

See here for a good discussion on the reasoning behind not changing it to JSON:


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