When I capture HTTP requests and responses with Burp suite, everything works fine except when I want to capture facebook.com responses, I get a strange response body which is in some unreadable format that is not HTML, but just some strange symbols (the response headers are ok and readable, but the body is not). Does anybody have an idea what could be the reason for that and if there is a fix? The burp cert is configured in my browser. And the response renders fine in my browser.


The response headers (without some values for which I'm not sure if I should post them) are:

HTTP/1.1 200 OK
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
Pragma: no-cache
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net *.atlassolutions.com blob: data:;style-src data: 'unsafe-inline' *;connect-src *.facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* *.akamaihd.net wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob:;
Cache-Control: private, no-cache, no-store, must-revalidate
Strict-Transport-Security: max-age=15552000; preload
Vary: Accept-Encoding
Content-Encoding: br
Content-Type: text/html
Date: Mon, 05 Sep 2016 22:09:00 GMT
Connection: close

And the first few bytes of the response body in HEX look like this:

0a 07 30 0c 00 e4 af 9f ab fe f7 e7 cb 7a 7b 41
  • 3
    Since you don't provide exactly what you see we cannot analyze it. But maybe you are looking at compressed data? Please provide at least the response header (without the real cookie values) and the first few bytes of the response body (as hex not "characters" so that one can have a look at the binary values). Commented Sep 6, 2016 at 4:37
  • Is it happening only with Facebook? Can you infer what kind of websites are giving you this kind of response?
    – one
    Commented Sep 6, 2016 at 6:33

1 Answer 1


The response of the server reply is Brotli encoded:

Content-Encoding: br

I think that the Burp Suite doesn't decode this, so you're seeing the compressed version of your response.

For more information about Brotli you can look here.


Until the Burp Suite supports Brotli, you can override the Accept-Encoding-Header as a workaround. Go to Proxy -> Options -> Match and Replace. There is allready a template named "Require non-compressed responses" that you can simply activate: Require non-compressed responses

  • I'd like to add that Brotli is currently only supported in Google Chrome and Opera - using another browser should result in another compression.
    – Lukas
    Commented Sep 6, 2016 at 13:07
  • I used Mozilla User-Agent and still got that encoding. I would appreciate it if anybody has a solution how to easily decode that with Burp. If not, I would accept this answer. Thanks! Commented Sep 6, 2016 at 15:39
  • 1
    Firefox supports also Brotli since version 44. I've added a workaround in my answer.
    – sven.to
    Commented Sep 6, 2016 at 18:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .