I have a wierd problem. If I inspect my WP pages using chrome element inspector I see two body tags thus:

<body cz-shortcut-listen="true">

This bit is to do with colorzilla (cz-shortcut-listen="true") in firebug it disappears. you have just 2 body tags with no classes.

The issue is not about the cz-shortcut-listen="true" bit coming from colorzilla. It is about the extra tag.

This duplication is causing styling and JS problems. If I view source then just a single


is displayed with no classes.

No classes from body_class() are displayed in either view but I can echo them out into the source quite happily when they are not within this line in header.php

  <body <?php body_class();?>>

simply adding

<?php body_class();?>

above or below the line that renders the body tag displays all the body classes quite happily so they are being set.

If I comment out the line that renders the body tag in header.php using php commenting this body tag is still rendered

<body cz-shortcut-listen="true">

This happens with all themes and also to users outside of my local network and in chrome AND firefox so it seems not to be a theme or local browser issue. (See also UPDATE 2 below)

Has anyone any idea what it might be, it is a major headache and I'm quite stumped as to what it could be or how to even go about working out what the problem is.

Staging site displaying the problem here: http://eco.clearintent.co.uk/

UPDATE: This is happening on every WP installation on the server so is not wp install or theme specific.

Running wordpress 4.2.4 Server is running Apache/2.2.29 PHP/5.3.29 Amazon Linux on an EC2 m3.medium instance.

UPDATE 2: Tried installing a vanilla wordpress on a new ec2 instance running apache 2.4 and php 5.6 just to see and it has the same issue! Doesn't affect non-wordpress websites. Happens across browsers and networks so not specific to my local setup.

UPDATE 3: Getting the site using wget from command line delivers the correct code WITH the body classes in the single body tag. - I wondered if (as suggested below) this indicated that javascript was to blame but when Iaccessed the site in chrome with javascript disabled the issue didn't resolve so that seems to mean javascript isn't the issue.

UPDATE 4 As per the answer below the issue does lies in the strange character present in the body tag however, deleting and replacing this line doesn't work. The only thing that seems to work is surrounding the first line in html comments and having an identical uncommented line below, thus:

<!--<body <?php body_class(); ?>>-->
<body <?php body_class(); ?>>-->

If I remove the top commented line then the error re-occurs on the newly typed body tag.
If I remove the body tag from the commented line but still have an empty comment thus:

<!-- -->
<body <?php body_class(); ?>>-->

Or I include the body_class function in the comment thus:

<!--<?php body_class(); ?>-->
<body <?php body_class(); ?>>-->

The behaviour reappears so the first body tag (even though commented) has to be present for the new one to render properly.

I have checked the Apache and php utf-8 encodings are in place. I checked in the browser that the page was seen as utf8 which it is. On the server

 file -bi header.php 

displays the file as ascii.

This gets wierder and wierder, I have a hack to get things working but not an understanding of what is happening.

Any thoughts on how to debug this would be very very gratefully received.



SOLUTION: see below. I added a separate answer for clarity.

  • Possible duplicate of stackoverflow.com/questions/13147210/… Aug 13, 2015 at 19:00
  • If it isn't showing up in view source but it is showing up in inspector, that means it's being injected either by a browser extension (link above suggests ColorZilla) or by JavaScript. Try using an Incognito window with no extensions and see if it still happens. Aug 13, 2015 at 19:01
  • Thanks for answering. This isn't about colorzilla. Colorzilla adds the attribute but not the additional body tag. This issue is visible in firebug aswell where there is no colorzilla attribute. Added another update. Aug 14, 2015 at 11:09
  • I tried incognito and the duplicate body persists but then I tried using wget from command line and no duplicate <body> is shown AND the body classes are displayed. What is this telling me? - Javascript injection is the issue? Aug 14, 2015 at 11:20
  • Can't see any such problem at eco.clearintent.co.uk. cz-shortcut-listen="true" is being added to the existing body tag only.
    – Domain
    Aug 14, 2015 at 12:02

3 Answers 3


I think this is the browser modifying the DOM due to a weird character you have in your body tag. When I view source in Firefox, I'm seeing the "character not recognized" box next to the body tag. This is also visible in Firefox inspector.

Modern browsers automatically fix issues in your HTML for you when rendering the page. For example, if you have a <table> without a <tbody>, the browser will add the <tbody> section for you, even though it isn't in your markup. What I think is happening here is that the browser is seeing a tag that is <bodyX> where X is a bad unicode character, and it's not recognizing it as a body tag, so it wraps the remainder of the content in a proper body tag, causing the duplication. This explains why it is not visible in view source (because view source is the literal source, not the modified source, which is visible in the inspector) and wget would produce the same behavior.

Try going into your theme's head file and deleting the body tag, then re-typing it, to remove any strange additional characters.

If that doesn't work, it is possible that there is something on the server that is incorrectly modifying the content of the body tag on the way out.

  • Hi, Thanks, this is definitely part of the issue but there is still some wierdness. See update 4. Would appreciate your thoughts. Thanks to you I have at least go the site working so much appreciated. I'll mark as accepted once I have fleshed this out as much as I can. Aug 15, 2015 at 23:44

I have posted an answer so this is more concise but have marked the helpful answer as accepted.

The initial issue was as @Kevin Fodness pointed out, the browser failing to see the <body tag as a body tag because of the strange 'character' inside it.

The strange character in the <body tag made me think. I had already investigated an exploit but had seen no exploited code BUT when I scanned with wordfence it identified some files as exploited. When I opened these - no exploited code visible. Hmmmm. UNTIL

I opened them in vi. Then a massive chunk of exploit was visible.

I'm guessing that the behaviour above (UPDATE 4) was because the exploit didn't detect that I had surrounded the first <body> tag in <!-- --> and so rendered it's nasty payload leaving my second <body> intact. Naturally, if I deleted the first then the first <body tag it detected was my new one so it dumped its filth in there.

Now that I have cleaned this exploit from all of the wp sites, the <body> renders fine.

What appeared to be a single character narfing the <body> was in fact a whole chunk of obfuscated code. I'm just very lucky I thought to use vi to open the file else I doubt I would have worked this out; I had no idea code could be obfuscated from nano in this way. Lesson - don't shy away from vi!


I was having the same issue.

I had

<body <?php body_class(); ?>>

with a space between "body" and the opening php tag. Removing the space fixed the issue:

<body<?php body_class(); ?>>

  • Whether or not there is a space would not have been responsible for your issue, or the asker's. Either would work, but with a space would be more correct. Mar 10, 2018 at 12:57

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.