Are iframes considered 'bad practice'? [closed] – Dev

The best answers to the question “Are iframes considered 'bad practice'? [closed]” in the category Dev.


Somewhere along the line I picked up the notion that using iframes is ‘bad practice’.

Is this true? What are the pros/cons of using them?


They’re not bad practice, they’re just another tool and they add flexibility.

For use as a standard page element… they’re good, because they’re a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to “sandbox” internal pages into an iframe so poor markup doesn’t affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don’t want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.

For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.


As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.

One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.

However I’ve seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.

Usually, if you can do it without an iframe, that is a better option. I’m sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.

With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.


Having worked with them in many circumstances, I’ve really come to think that iframe’s are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.

Consider the possibilities … if used for parameterized content, they’ve created an interface. And in a professional site, that interface requires an SLA and version management – which are almost always ignored in rush to get online.

If used for active content – frames that host script – then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.

If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.

So, although, occaisionally useful within a site, they are rather unsuited to mashups. You’re far better looking at real portals and portlets. Worse, they are a darling of every web amateur – many a tech manager has siezed on them as a solution to many problems. In fact, they create more.


It’s ‘bad practice’ to use them without understanding their drawbacks. Adzm’s post sums them up very well.

On the flipside, gmail makes heavy use of iFrames in the background for some of it’s cooler features (like the automatic file upload). If you’re aware of the limitations of iFrames I don’t believe you should feel any compunction about using them.