Twitch Embedded Player Migration - Timeline Update

Yes. At this time, we are currently sending Content-Security-Policy-Report-Only response headers for the requests when the parent and migration parameter are provided. migration should be set to true.

Here is an example:

    height="720" width="1280" frameborder="0" scrolling="no" allowfullscreen="false">

If you go into the network traffic of your browser and look at the request to, you should see the Content-Security-Policy-Report-Only header. If the everything is fine, you will not see anything in the browser console. If there is a potential error with the embed, you will see the following message in the developer console (note the embed will still occurr as this is just a report).

[Report Only] Refused to frame '' because an ancestor violates the following Content Security Policy directive: "frame-ancestors https://MYDOMAIN".

Sometime before June 10, we may always return the report header. As of June 10, we will always return CSP header.

Hi twitch dev,

There seems to be an issue with the domain name validation.

We require the parent to be an ip address for development testing e.g. parent=

When an ip address is used, the error we receive is “parent query string value contains invalid domain name”. moonstar_x reported the same issue above.

Test url:


I’m a bit confused as to how Chrome handles the Content-Security-Policy-Report-Only header. In a staging environment using a cert issued by a CA, no console message is logged. But in local environments with a self-signed certificate, Chrome spits out a [Report Only] error. This doesn’t give much confidence that things won’t break for local development after June 10.

Here’s some findings using the player iframe embed.

Content-Security-Policy-Report-Only: frame-ancestors localhost
[Report Only] Refused to frame ‘’ because an ancestor violates the following Content Security Policy directive: “frame-ancestors localhost”.

400 Bad Request

400 Bad Request

400 Bad Request

This also doesn’t work ( mapped to

Content-Security-Policy-Report-Only: frame-ancestors
[Report Only] Refused to frame ‘’ because an ancestor violates the following Content Security Policy directive: “frame-ancestors”.

I’ve spent over 4 hours trying to get local development working with no luck. Tried hosting locally on port 80 and 8000. Tried different combinations of scheme, hostname, port for the parent. Either a 400 Bad Request is returned from or Chrome just doesn’t like localhost specified in frame-ancestors.

Not sure what to do at this point. I don’t want to disable CSP in the browser. There’s gotta be an easier way. You can repro this easily by using a starter Next.js, Gatsby.js, or Create React App and embed the twitch player.

Thanks for your reply.

As other users mention, I’m also having “invalid domain name” issue when domain is an ip address, which is a problem in development environment.

Hope this can be fixed.

@moonstar_x @mikegreen @kaldune02 @bs1

The team has provided additional information regarding local development and a change to go along with the June 10 update to fix the situation described below.

localhost and anything in the IP range is an acceptable value for parent (e.g. parent=localhost or parent= As it stands at the moment though, since the player is served over HTTPS, so does your local development for successful CSP URL matching according to the spec (added the link for reference only if you’re curious). In other words, if you specify parent=localhost, your local development needs to be served on https://localhost:443 or if you specify parent=, your local development needs to be served on Note that the CSP does not require the HTTPS connection to actually have a valid certificate.

All of that said and recognizing that this is not ideal for local development, the team is going to implement a change next week that makes an exception for local development. With that change, localhost and the IP range will be able to accept HTTP and any port (though the port should not be specified in the parent value as ports are not valid in the expression). In other words, with that change, you will not need to have HTTPS set up for local development.

Hopefully this helps explain the current situation and how it’ll be addressed next week.

1 Like

Thanks @jbulava

If you have to restrict the ip range then we’d like to request the 192.168.x.y range to be included, which references servers on the local network.

When we do testing for mobile devices, we aren’t able to access 127.0.0 range because the development server is running on another computer (and not on the phone itself).

I’ll pass along this request. Out of curiosity, would you be willing to share a link to your app here or in a DM? It would be great to pass along your use case with a working example.

This is only an issue during development and testing which aren’t public links.

Here’s the link that the Twitch JS API generates automatically:


Thanks for sharing the testing link. Though I was looking for your App Store link if it’s in production (i.e. I’d like some examples of mobile apps using Twitch Embeds to share as it is a lesser known use case.

Oo we are embedding in a website like a normal use case. However, we do a lot of testing using the browsers on mobile devices since iOS and Android have different ways of working and usability concerns e.g. one platform might only allow autoplay if muted

Ah, got it! That makes sense.

Hey. How to hide topBar? Will the new version of Player Twitch have adaptability? Or will it still work crookedly? If it is not possible to find out all levels of nesting, will the player work?

Anyone have issues with embed into wordpress with the new iframe? I cant get it to work.

if you are using the JS libs it’ll handle it for you otherwise you need to append & to the end of the URL

Im using.
< iframe src=“” frameborder=“0” allowfullscreen=“true” scrolling=“no” height=“378” width=“620”>

Oh i just fixed it by removing the www.

With the new changes in effect, it seems to be impossible to embed video or chat on a custom SSL domain for a local dev environment not running on the default port for SSL. Always get an empty frame with the “ refused to connect.” browser error.

Basically we have a local loopback to our company dev domain, with a self-signed SSL cert, that runs the frontend portion of our app on port 3000. If I force the app port to be 443 (default SSL port) the embed works fine, but when using the custom port the embed fails to load, and makes it impossible to use in our dev environment. In both cases, the automatically injected parent value for the live stream embed is our fully qualified domain name without the protocol prefix or the port suffix (adding either of these results in the twitch error message indicating that the embed has been misconfigured).

@jbulava could you maybe have someone check this, it should be pretty simple to reproduce with a Create React App set up with HTTPS=true (this will also cause it to auto-generate the self-signed certs) and a custom non-localhost hostname, running at the default 3000 port

You probably want

<iframe src=“” frameborder=“0” allowfullscreen=“true” scrolling=“no” height=“378” width=“620”>

For full coverage of your website if non www/with www redirects to the other of leaves it as is

1 Like

I use the chat embed inside an Electron app. the new CSP blocks apps running locally embedding if you use electron. The origin: "file://" is blocked by the csp. Is there anyway around this?

I get the refused to connect error when accessing my website via Chrome on Android. It works fine from desktop computers in both Chrome and Firefox.

Any idea what’s going on?

Edit: It seems to work on my Android phone but not on my slightly older Android tablet.

Edit 2: Nevermind. It seems Chrome on my Android tablet cached an old version of the embed code and I had to explicitly flush the browser history which fixed the issue.