|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #49366 Make slash escaping optional in json_encode()
Submitted: 2009-08-25 23:32 UTC Modified: 2010-09-16 15:53 UTC
Avg. Score:4.2 ± 1.0
Reproduced:14 of 14 (100.0%)
Same Version:12 (85.7%)
Same OS:6 (42.9%)
From: don at smugmug dot com Assigned: aharvey (profile)
Status: Closed Package: JSON related
PHP Version: 5.3.0 OS: CentOS 5.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
25 - 19 = ?
Subscribe to this entry?

 [2009-08-25 23:32 UTC] don at smugmug dot com
When given a string with slashes in it, despite the JSON docs suggesting 
that's legal, json_encode escapes them anyway. says "any-Unicode-character-except-"-or-\-or 

JSONLint at also validates slashes that aren't 
escaped as valid.

This adds response weight, and makes further processing much more 

Reproduce code:
$vars['url'] = "";
echo json_encode($vars);

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-26 08:50 UTC]
It's not incorrect to escape slashes. It's also suggested on the RFC to do so. Just look at the chart on for string..

But since it isn't wrong either NOT to escape them, I'll just reclassify this. We can add another option to that optional bitmask "options". 
 [2009-10-21 21:14 UTC] jemptymethod at acm dot org
I concur with the suggested course of action making the escaping of slashes controllable with a flag as I'm experiencing the same issue as the OP albeit on Debian (rather than CentOS)
 [2010-08-08 14:43 UTC] jd2 at dilltree dot com
Totally agree.  This is needed for anything such as a REST service that wants to 
return JSON with valid urls.
 [2010-09-16 15:53 UTC]
Automatic comment from SVN on behalf of aharvey
Log: Implemented FR #49366 (Make slash escaping optional in json_encode()).
 [2010-09-16 15:53 UTC]
-Summary: json_encode incorrectly escapes slashes (/) +Summary: Make slash escaping optional in json_encode() -Status: Open +Status: Closed -Package: Feature/Change Request +Package: JSON related -Assigned To: +Assigned To: aharvey
 [2010-09-16 15:53 UTC]
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

I've implemented this on trunk via a json_encode() option called JSON_UNESCAPED_SLASHES. The default behaviour remains to escape slashes.
 [2011-12-15 22:05 UTC] dtremblay dot fafard at gmail dot com
Actually, I can't find any reason why is escaping slashes by default and create an option to remove this feature.  Usually, when you want something added (e.g. Escaping Slashes), you use an option to recreate the feature wanted. So why is the option used to REMOVE a feature? Options exists to add features, not remove them?? Where am I wrong?
 [2011-12-16 01:37 UTC] don at smugmug dot com
I totally agree that this should just be the default, rather than some new 

Both ways are 100% JSON compliant, but one (the PHP chosen method) is far less 
common, has a significantly larger footprint on lots of common types of data, and 
is harder for humans to read.  I see no benefit t
 [2012-03-02 17:26 UTC] diego dot pasc at tiscali dot it
I also agree that NOT ESCAPING should be the default
 [2012-12-03 09:31 UTC] php dot net at site dot lanzz dot org
To me, this issue is just magic quotes being still alive and well, in the year 
2012. I thought the lesson of "don't overquote when you don't have to" has been 
learned already? Granted, this issue is marginally better than the magic quotes 
fiasco, as it doesn't actually change the semantics of the escaped value.
 [2017-11-15 07:59 UTC] d at kjdkj dot cpm
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jul 16 20:01:29 2024 UTC