How to tag pages

When you add one of these tags to an article, you help the automated tools to more accurately generate landing pages, tables of contents, and so on. Our new search system also uses these tags to help our readers locate reference or guide information easily.

We use the following tags to denote the appropriate document type:

Intro

The article provides introductory material about a topic. Ideally, each technology area should have only one "Intro".

Reference

The article contains reference material about an API, element, attribute, property, or the like.

Landing

The page is a landing page.

Guide

The article is a how-to or a guide page.

Example

The article is a code sample page or has code samples (that is, actual snippets of useful code, not one-line "syntax examples").

By identifying the article's topic area, you help generate better search results (and landing pages and navigation as well).

While there's some room for flexibility here as we identify new topic areas, we try to limit ourselves to the names of APIs or technologies. Some useful examples include:

• HTML
• CSS
• JavaScript (notice the capital "S"!)
• Document
• DOM
• API for each API's overview, interface, method, and property
• Method for each method of an API
• Property for each property of an API
• Graphics
• SVG
• WebGL
• Tools
• Web
• Element
• Extensions and WebExtensions for WebExtension documentation

In general, the topic identification tag should be the name of an interface with a number of related pages (like Node, which has many pages for its various properties and methods) or the name of an overall technology type. You might tag a page about WebGL with Graphics and WebGL, for example, but a page about <canvas> with HTML, Element, Canvas, and Graphics.

These tags are used in Mozilla-specific content only:

• Mozilla
• Firefox
• Gecko
• XUL
• XPCOM

Within the API reference, the following tags help to identify the part of API an article covers:

Interface

The main article for an interface should have this tag. For example, RTCPeerConnection.

Constructor

Each interface may have up to one page tagged "Constructor"; this is the interface's constructor. The page should have the same name as the interface, like RTCPeerConnection().

Property

Every article describing a particular property within an interface needs this tag. See RTCPeerConnection.connectionState for example.

Method

Each article documenting an interface method needs this tag. See RTCPeerConnection.createOffer() for example.

In addition, reference pages need to include interface, property, and method names among their tags. This is illustrated in the following examples:

• The interface RTCPeerConnection: Include the tag RTCPeerConnection along with other relevant tags like Interface, WebRTC, WebRTC API, API, and Reference.
• The method RTCPeerConnection.createOffer(): Include the tags RTCPeerConnection and createOffer (note no parentheses in tag names!) along with the other relevant tags, including Method, WebRTC, WebRTC API, API, and Reference. Consider including tags like Offer and SDP, which are also relevant here.
• The property RTCPeerConnection.iceConnectionState: Include the tags RTCPeerConnection and iceConnectionState along with the other relevant tags, including Property, WebRTC, WebRTC API, API and Reference. Also consider including ICE.

To help readers understand how viable a technology is, use these tags to label articles with respect to the status of the technology's specification. This isn't as detailed as actually explaining what the spec is and how far the technology has come in the specification process (that's what the Specifications table is for), but it helps the reader judge, at a glance, whether it's a good idea to use the technology described in the article.

Tags in this category include:

Read-only

The property or attribute is read-only.

Non-standard

The technology or API is not part of a standard, whether it's stable or not in any browsers which implement it (if it's not stable, it should also be Experimental). If you don't use this tag, your readers will assume the technology is standard. The browser compatibility table on the page should clarify which browser(s) support this technology or API.

Deprecated

The technology or API covered on the page is no longer recommended. It might be removed in the future or might only be kept for compatibility purposes. Avoid using this functionality.

Experimental

The technology is not standardized and is an experimental technology or API that may or may not ever become part of a standard. It is also subject to change in the browser engine (typically only one) that implements it. If the technology isn't part of any specification (even in draft form), it should also have the Non-standard tag.

Needs Privileges

The API requires privileged access to the device on which the code is running.

Certified Only

The API only works in certified code.

These tags are no excuse to leave out the browser compatibility table in your article! That should always be present. For more information on the definitions of deprecated and experimental, see the Experimental, deprecated, and obsolete documentation.

Use these tags only for guides and tutorials (that is, pages tagged Guide) to help users choose tutorials based on how familiar they are with a technology. There are three values for this:

Beginner

Articles designed to introduce the reader to a technology they've never used or have only a passing familiarity with.

Intermediate

Articles for users who have gotten started with the technology but aren't experts.

Advanced

Articles about stretching the capabilities of a technology and of the reader.

The writing community uses these tags to label articles as requiring specific types of work. Here's a list of the ones we use most:

Draft

The article is not complete and is still actively being updated (although it's also possible it's been forgotten about). Try to check with the most recent contributors before making changes to avoid potential content collisions.

NeedsCompatTable

The article needs a table to specify compatibility of a feature across browsers. See here for a guide on contributing to browser compatibility.

NeedsContent

The article is a stub or is otherwise lacking information. This tag means that someone should review the content and add more details and/or finish writing the article.

NeedsExample

The article needs one or more examples to help illustrate the article's point. These examples should use one of the code example styles.

NeedsLiveSamples

The article has one or more examples that need to be updated to use the live sample system.

NeedsMarkupWork

The article needs improvement to the page markup (usually because the page content consists mostly or entirely of <p> tags).

NeedsSpecTable

The article needs a table to indicate on which specification document(s) the feature was defined.

NeedsUpdate

The content is out of date and needs to be updated.

l10n:exclude

The content is not really worth localizing and will not appear on localization status pages.

l10n:priority

The content is important and should be marked as a priority for MDN translators. Shows up in an extra priority table on localization status pages.

To put it all together, to each page you assign tags from the different categories explained above. Some examples are shown below:

• A tutorial about WebGL for beginners will have the following tags:
  • WebGL
  • Graphics
  • Guide
  • Beginner
• A reference page for <canvas> will have the following tags:
  • Canvas
  • HTML
  • Element
  • Graphics
  • Reference

There are several kinds of tag problems you can help fix.

Generally, all articles should have at least a "document type" and a "topic type" tag. Usually other tags are appropriate as well, but if you can help us ensure that the minimum tags are present, you'll be a documentation hero!

Please fix any documents that have tags that don't follow the standards described on this page. Note that you may occasionally see some localized tags (such as Référence) showing up on some English pages. This was due to a bug in Kuma, which caused the tags to reappear even if they were deleted. That bug has since been fixed, so any remaining localized tags can be cleaned up if they're spotted.

If you're looking at an article about HTML and it's tagged JavaScript, that's probably wrong! Likewise, if an article discusses Mozilla internals but has a Web tag, that's probably wrong too. Remove these tags and add the right tags if they aren't already there. Please also correct misspelled tags (e.g., Javascript will still match, since tags are case-insensitive, but let's not be sloppy!).

If an article has some but not all of the tags it needs, feel free to add more. For example, if a page in JavaScript reference is (correctly) tagged JavaScript but nothing else, you're invited to tag the page Reference or another type as well!

This insidious beast is the most revolting tag problem of all: some web vermin has deposited its droppings in the page tags (like "Free warez!" or "Hey I was browsing your site and wanted to ask you if you could help me solve this problem I'm having with Flash crashing all the time"). We've got to delete these right away! They're ugly, they're hard to manage if they're allowed to linger too long, and they're terrible for SEO.