HTML Guides for frame
Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.
The <frame> element is obsolete, so the content each frame loads has to move into the page itself or into an <iframe> inside a normal <body>.
A <frame> only works inside a <frameset>, where it loads a separate HTML file into one pane of the browser window. The validator reports this message once for every <frame> on the page, and the <frameset> around them gets a message of its own. Moving the frames into a <body> doesn't help: the parser drops a <frame> there and reports it as a stray start tag. The frames and the frameset have to be replaced together, and when the frameset only wraps another site in a single frame, an HTTP redirect to that site replaces both.
What replaces each frame depends on what it holds. A header or menu that every page shares belongs in the page itself, written directly or pulled in with a server-side include or a template, so it lives at the same URL as the content around it. A document that has to stay separate can load in an <iframe>. Iframes take src and name just as frames did, so links with a matching target keep loading into them, and the validator stops warning that name is never allowed on <frame>. Give each iframe a title describing what it shows, since screen readers announce it.
The presentation attributes of a frame don't carry over. On an <iframe>, frameborder, scrolling, marginwidth and marginheight are obsolete too, and the validator warns about each one. Remove the border with border: 0 in CSS. Scrollbars and margins belong to the document loaded inside, so set overflow and margin in that document's own stylesheet. noresize needs no replacement, since an iframe has no draggable border between panes.
Invalid example
A header frame above a catalog frame:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Garden supplies</title>
</head>
<frameset rows="80,*">
<frame src="header.html" scrolling="no" noresize frameborder="0">
<frame src="catalog.html" frameborder="0">
</frameset>
</html>
Valid example
The header is part of the page (on a real site it would come from an include), and the catalog keeps loading from its own file in an iframe:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Garden supplies</title>
<style>
iframe {
width: 100%;
height: 80vh;
border: 0;
}
</style>
</head>
<body>
<header>
<a href="/">Garden supplies</a>
</header>
<iframe src="catalog.html" name="catalog" title="Product catalog"></iframe>
</body>
</html>
The <frameset> element is obsolete, so a page split into frames has to become a normal page with a <body>, using CSS for the layout and <iframe> or server-side includes for the shared parts.
A frameset document has a <frameset> where the <body> would go, and each <frame> inside it loads a separate HTML file into one pane of the window. The HTML standard lists <frameset>, <frame> and <noframes> as obsolete. Browsers still render framesets so old sites keep working, but the validator reports the <frameset> once and then each <frame> and <noframes> with a message of its own. The rows and cols attributes go away with the element and aren't reported separately.
Frames cause trouble beyond validation. The address bar keeps showing the frameset's URL whatever is loaded inside it, so a visitor can't bookmark or share a specific page, and search engines can send people straight to a framed page without the navigation that was meant to surround it.
The fix depends on what the frames were for. When they hold shared navigation, the usual answer is one complete page per URL, with the navigation pulled in on the server through an include, a template or a static site generator. When a pane really has to load other documents, an <iframe> inside a regular <body> does that job, sized with CSS and given a title so screen readers can announce it. A frameset with a single frame that fills the window, such as rows="100%,*", is often the "masked forwarding" a domain registrar sets up to show another site under a different domain. In that case, replace it with an HTTP 301 redirect to the real site.
Invalid example
A manual with a table of contents on the left and the chapter on the right:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Product manual</title>
</head>
<frameset cols="25%,75%">
<frame src="contents.html">
<frame src="chapter-1.html">
</frameset>
</html>
Valid example
The table of contents moves into the page, and an <iframe> loads each chapter that its links target:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Product manual</title>
<link rel="stylesheet" href="manual.css">
</head>
<body>
<nav>
<ul>
<li><a href="chapter-1.html" target="chapter">Chapter 1</a></li>
<li><a href="chapter-2.html" target="chapter">Chapter 2</a></li>
</ul>
</nav>
<iframe src="chapter-1.html" name="chapter" title="Chapter text"></iframe>
</body>
</html>
body {
display: flex;
height: 100vh;
margin: 0;
}
nav {
flex: 0 0 25%;
}
iframe {
flex: 1;
border: 0;
}
The iframe keeps the two-pane layout, but every chapter still shares one URL. Publishing each chapter as its own page, with the table of contents included on the server, gives every chapter an address people can bookmark and link to.
The validator warns about name on a <frame> because the <frame> element itself is obsolete, and the warning goes away when the frame becomes an <iframe>, which accepts name.
In a frameset, name gives a frame the target name that other documents use to load pages into it. A link with target="content" opens its page in the frame named content, a form with the same target shows its response there, and a script can reach the frame through window.frames["content"]. Menus built with frames depend on it: every link in the menu frame points at the frame that holds the content. Browsers still honor these names, which is why the frames keep working.
The validator checks name on every element against a short list of elements that define it: button, details, fieldset, form, iframe, input, map, meta, object, output, select, slot and textarea. <frame> isn't on that list because it's obsolete. The validator reports this check as an informational message rather than an error, so it shows up as a warning, once for each named frame. The errors come from the elements themselves: each <frame> gets a message saying it's obsolete, and so does the <frameset> around it. Other attributes common on old frames, such as frameborder, scrolling and noresize, get no message on a <frame>.
Deleting name silences the warning but breaks every link and form that targets the frame, and the obsolete errors stay. Replace the frameset instead. A frame whose content moves into the page itself, such as a menu, no longer needs a name, since nothing loads into it. A frame that becomes an <iframe> keeps its name, so links with a matching target keep loading into it.
Invalid example
The links in menu.html use target="content" to open each recipe in the second frame:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Recipe box</title>
</head>
<frameset cols="200,*">
<frame src="menu.html" name="menu">
<frame src="welcome.html" name="content">
</frameset>
</html>
Valid example
The menu moves into the page, and the iframe keeps the name content, so the links still load into it:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Recipe box</title>
</head>
<body>
<nav>
<a href="soups.html" target="content">Soups</a>
<a href="desserts.html" target="content">Desserts</a>
</nav>
<iframe src="welcome.html" name="content" title="Recipe"></iframe>
</body>
</html>
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
1K Weekly
1,000 monthly checks. Cancel anytime.
Get 1K Weekly →Join teams across 40+ countries