A fairytale called ‘PHP and the ‘\ufeff’ character’

oktober 11, 2019

Not too long ago I built an API for one of my customers. They needed a very (read: very) basic response from their serverside script to the client.

The API was built in less than half an hour (using existing technologies and security best-practices that were already in place). And so I started sending some requests to the endpoint with Postman, and god I truly love Postman… Anyways, I found that the response I got looked like the type of response I would expect and could use. It was a simple JSON object, with ‘some’ nested variables. Nothing scary, like I said.

Then I started making the requests from the clientside. I used Jquery’s own $.ajax to make the requests and I obviously toggled the response between .error and .success.

The code

The code was simple and looked like this:

    url: 'MyEndPointURL?getMyItems=1',
    type: "GET",
    dataType: 'json',
    success: function(items, textStatus, jqXHR) {
        // Do something with the data
        $.each(items, function(index, item) {
    error: function(jqXHR, textStatus, errorThrown) {

And the backend looked like this:

	// Get the objects with a method declared in SomeController.php
	$myObjectArray = GetMyObjects(); 
	 echo json_encode($myObjectArray);

The issue

As I said; the response I saw in Postman looked valid to me. I basically got a list of x items all with valid values and with the response header ‘application/json’. However, I did not receive console log’s printing out items. Instead; I got this error:

Weird, since the Network preview tab in Chrome clearly showed all my items with valid values:

After lots and lots of code-checking, Googling and rage (and I admit; I almost send the whole array of objects a text to be parsed by JS’s JSON.Parse just to find out it still couldn’t be parsed) I stumbled upon a little red dot in front of the result in the response tab of the network tab in Chrome:


Because it does not ‘break’ the preview it didn’t occur to me the JSON that was returned might have been invalid. Well; I thought wrong. This little red dot, as I found out, was the ‘\ufeff’ character. A character that is called the ‘Byte Order Mark’ (BOM), more info found here. Because I did include (or required) a class to be used in my API backend it apparently added the BOM in front of my response. PHP sees this as a blank line when returning any content from a page and thus added the BOM. I was unable to find any file that was included in my API backend that used the BOM character, or anything alike.

The solution

I resolved this issue by using PHP’s function ob_clean(). Ob_Clean clears the contents of the output buffer. Therefore I called this method before I started my output from the API. The issue resolved immediately, and PHP lived happily ever after (without \ufeff).

Posted in ProgrammingTags:
Related Posts

Originally posted at Mavention.nl. Searching. One of the most crucial activities performed on datasets. Think of a world with lots of data, but no possibility to filter relevant info for yourself. Sounds pretty stone-age right? Thankfully we have lots of options to perform the…

Originally posted at Mavention.nl. Have you ever asked yourself when writing a piece of code if it could perform faster? The answer is most likely: yes. Programming is not only about writing functional blocks. Speed and code efficiency are directly connected to user satisfaction,…