MFW another API just stops working without returning any errors

How to fix Twitter embed in SharePoint

This post was most recently updated on February 25th, 2019.

Reading Time: 5 minutes.

Twitter has always been (relatively) good for developers – except for anyone who’d like to embed anything – hence making it possible to interact with their contents on other sites than Twitter. I guess it’s understandable, but they seem to hate anyone trying to embed feeds, searches or anything on their sites. And they express their hate by making the developers’ lives more difficult… This time by silently breaking the embed script in a way, that’s tricky to work around.

The Problem

In February 2018, Twitter announced that their widgets will start rendering fallback markup on IE9 and IE10 “in the near future”. Since SharePoint 2013 and 2016 are locked in document mode of IE 10 (i.e. using Internet Explorer on SharePoint sites causes the user agent to be roughly that of IE10), that means trouble for SharePoint admins.

Why? Basically everyone, who’s using Twitter embeds on SharePoint, will be seeing empty feeds henceforth. No matter if you’re using Internet Explorer 9, 10 or 11.

Well, everyone but SharePoint Online users, since SharePoint Online renders in whatever mode Microsoft chooses. It’s usually either IE 10 or IE 11, sometimes “edge” (latest IE mode available, NOT the browser). And as a result, Twitter embeds sometimes work, sometimes they don’t.

So for SharePoint Online users, you’ll have to verify the used document mode before figuring anything else out.

Anyway – the change’s immediate effects were surprisingly small. Widgets still rendered, until early May 2018. Then, we started getting reports of Twitter being utterly broken – the embed being completely empty without any fallback rendering whatsoever.

This post describes how to fake the user agent for the Twitter embed, and avoid their annoying IE-block, which they’re applying in the laziest possible way – by checking if User Agent contains Internet Explorer 10 (or earlier), and if it does, by stopping their script from executing.

On to the investigation

So the embeds are left completely empty, and there’s nothing in the console, and even the network tab is empty after the inclusion of the Twitter’s JavaScript library.

Annoyingly, the embed just fails silently, without telling what’s wrong. Looking at the code, it looks like it just checks the user agent for MSIE10 or less, and ends the execution. No logging, no output, no nothing.

Thanks a lot, Twitter, much appreciated! It would’ve been nice to get a fallback of sorts, or at least an error message or some logging. But I guess not, then.

What’s even worse, is that it applies to IE11 users, too – if they’re in SharePoint, or on a site that’s running in compatibility mode (such as all sites on “intranet” zone). And since IE seems to be most actively used in large organizations, especially on internal communication channels, Twitter just decided to block the majority of IE users in the world from accessing their service via embeds. 


Luckily, there’s a dirty hack for this situation!

Solution: Spoofing the user agent to fix Twitter

This fix applies to pretty much any website, but since my main concern is SharePoint, I’m mainly talking about applying the fix there.

So, SharePoint in intranet or local zone will jump into compatibility mode – which in turn sets the document mode to IE10, even in IE11. What makes things worse, is the fact that you shouldn’t change the document mode of SharePoint 2013/2016/2019 – and not really in SharePoint Online either, if you happen to encounter the issue there.

You should not edit master pages, and if you do, you’ll probably break a dozen OTHER things, since SharePoint relies on being shown in IE10 mode (like IE11 does in compatibility mode – more info about that here).

And even if you don’t have compatibility mode set on (which will lead you to run into other issues with SharePoint), you can’t really trust your users to change the document mode to anything else, so you’re left with changing it via code.

That way, we can only change it on the pages where Twitter exists, thus isolating the changes and hence the risks of breaking SharePoint completely. The code below is something you can selectively insert on the pages where you have Twitter embed.

A low-tech solution would be to throw this piece of code right here on a page. The easiest way would be by inserting it into a script editor web part. This same script works in other CMSs than SharePoint as well.

<script type="text/javascript">
function setUserAgent(window, userAgent) {
    // Works on Firefox, Chrome, Opera and IE9+
    if (navigator.__defineGetter__) {
        navigator.__defineGetter__('userAgent', function () {
            return userAgent;
    } else if (Object.defineProperty) {
        Object.defineProperty(navigator, 'userAgent', {
            get: function () {
                return userAgent;
    // Works on Safari
    if (window.navigator.userAgent !== userAgent) {
        var userAgentProp = {
            get: function () {
                return userAgent;
        try {
            Object.defineProperty(window.navigator, 'userAgent', userAgentProp);
        } catch (e) {
            window.navigator = Object.create(navigator, {
                userAgent: userAgentProp
  /* First we check if the User Agent matches to MSIE at all */
  if (window.navigator.userAgent.indexOf('MSIE ') >= 0) {
    setUserAgent(window, "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136");
} catch (e) {
<!-- the Twitter a-element and the platform/js code goes here -->
<script async="" src="" charset="utf-8"></script>

This piece of code uses a function (from here), to change the User Agent of the browser runtime.

This particular User Agent (“Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136”) is actually for Microsoft Edge, as Twitter supports that. This causes the annoying, execution ending User Agent -string check to fail in Twitter’s code… :)


Updated 18.1.2019, note this: At least in some scenarios, this hack might cause issues with page responsiveness. And of course it will – you’re messing with the user agent, so there’s a decent chance you’ll mess up some iframe-based functionality – such as a Twitter embed :)

The good news is, that the effect is local only to the page, where you’re applying the workaround on. The current solution only needs to be applied to different flavors of Internet Explorer – so while setUserAgent() -function works with most, the code sample only should run for IE.

I’ve updated the sample to reflect this, to minimize any side effects. Thanks for the heads-up, Tuukka!

Further reading

If you want to further tweak the embed, there’s a number of parameters you could use. For example, you can limit the number of shown tweets (probably the most typical scenario). Refer to these pages for a reference of attributes you could use:

0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments
Didier Peinke

Hi, Earlier this year I use your code to emblem twitter on Sharepoint 2010 which it working fine. But earlier this week it sudden stop working. Maybe twitter has changed something or i dont know if it my IE issue. (Chrome work fine). Can you have a look. thank


I’m in the same boat is Didier. I put the code on our SharePoint and it fixed the issue. However I noticed today the twitter feed stopped working on IE. However the Twitter feed does work in Chrome.

Would it be possible to set the user agent to a different browser? I’m not sure if I’m reading the code correctly but it looks like it’s switching it to and using “Mozilla/5.0 (Windows NT 10.0)…” Maybe twitter has decided it doesn’t like this browser anymore.


Indeed. Don’t know why it don’t show on IE but shoe on chrome. Hopefully there will be fix. As my client is meddling me about it.


Hi I am having the same problem, the twitter feed stopped working suddenly in IE 11. Do you have any solution for this?


I’m not sure the consequences of this, but I did find this as an offered fix somewhere…

Like I said, I’m not sure what the repercussions might be across this site… But in my testing it seems to have fixed the Twitter issue.


Is it possible to have a single site page to with a different meta-tag so have: IE11 Tag on my home page, whilst the master page has IE10?


I did some testing and substituted a newer version of Edge in the script but it still didn’t work. Then I decided to copy the code that loads the twitter feed into a HTML file on my desktop so I didn’t need to keep changing the code on SharePoint. What I found was when I ran my code from the desktop it would ask me “Internet Explorer restricted this webpage from running scripts or ActiveX controls” with a button “Allow Blocked Content”. When I run click the “Allow Blocked Content” the Twitter feed loads in IE and works. This tells me it’s a security setting not the code. I tried putting SharePoint in Trusted Sites and even in the “Local Intranet” site but it won’t load.

Hopefully someone can shed some light on this.


Did you simply put just this code into a HTML file and load it into a browser – just I’ve done that and get the Allow Content pop-up, but still nothing is shown.


Sorry I realised my mistake, I had forgotten to add the link to our twitter feed back in


Ugh – quit working for me, too.


I also have this issue. It is working with Chrome and Edge. This functions dont seems to be working anymore. I use this String as Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763


Unfortunately this has been something we’ve noticed on our SharePoint site as well ,hopefully an update to this script will come soon!


Even I got the same issue and I am not able to find workaround on this. Twitter feed load correctly in IE 11 but not with iE10