Commonly-used macros

This page lists many of the general-purpose macros created for use on MDN. For additional how-to information on using these macros, see Using macros.

See Other macros for information on macros that are infrequently used, are used only in special contexts, or are deprecated.


MDN provides a number of link macros for easing the creation of links to reference pages, glossary entries, and other topics.

Link macros are recommended over normal Markdown links because they are succinct and translation-friendly. For example, a glossary or reference link created using a macro does not need to be translated: in other locales it will automatically link to the correct version of the file.

The Glossary macro creates a link to a specified term's entry in the MDN glossary. This macro accepts one required parameter and one optional parameter:

  1. The term's name (such as "HTML"): {{Glossary("HTML")}} yields HTML
  2. Optional: The text to display in the article instead of the term name: {{Glossary("CSS", "Cascading Style Sheets")}} yields Cascading Style Sheets

Linking to pages in references

There are macros for locale-independent linking to pages in specific reference areas of MDN: JavaScript, CSS, HTML elements, SVG, etc.

The macros are easy to use. Minimally all you need to do is specify the name of the item to link to in the first argument. Most macros will also take a second argument allowing you to change the display text (documentation can be found at the links in the left-most column below).

Macro Links to page under Example
CSSxRef CSS Reference (/Web/CSS/Reference) {{CSSxRef("cursor")}} results in cursor.
DOMxRef DOM Reference (/Web/API) {{DOMxRef("Document")}} or {{DOMxRef("document")}} results in Document,
{{DOMxRef("document.getElementsByName()")}} result in document.getElementsByName()
{{DOMxRef("Node")}} result in Node.
You can change the display text using a second parameter: {{DOMxRef("document.getElementsByName()","getElementsByName()")}} results in getElementsByName().
HTMLElement HTML Elements reference (/Web/HTML/Element) {{HTMLElement("select")}} results in <select>
JSxRef JavaScript reference (/Web/JavaScript/Reference). {{JSxRef("Promise")}} results in Promise
SVGAttr SVG attribute reference (/Web/SVG/Attribute). {{SVGAttr("d")}} results in d
SVGElement SVG Element reference (/Web/SVG/Element). {{SVGElement("view")}} results in <view>
HTTPHeader HTTP headers (/Web/HTTP/Headers). {{HTTPHeader("ACCEPT")}} results in ACCEPT
HTTPMethod HTTP request methods (/Web/HTTP/Methods). {{HTTPMethod("HEAD")}} results in HEAD
HTTPStatus HTTP response status codes (/Web/HTTP/Status) {{HTTPStatus("404")}} results in 404

Previous, Next, and PreviousNext provide navigation controls for articles which are part of sequences. For the single-way templates, the only parameter needed is the wiki location of the previous or next article in the sequence. For PreviousNext, the two parameters needed are the wiki locations of the appropriate articles. The first parameter is for the previous article, and the second is for the next article.

Code samples

Live samples

There are templates for almost every large collection of pages. They typically link back to the main page of the reference/guide/tutorial (this is often needed because our breadcrumbs sometimes can't do this) and put the article in the appropriate category.

  • CSSRef generates the sidebar for CSS reference pages.
  • HTMLSidebar generates the sidebar for HTML reference pages.
  • APIRef generates the sidebar for Web API reference pages.

General-purpose formatting

Inline indicators for API documentation

optional_inline and ReadOnlyInline are used in API documentation, usually when describing the list of properties of an object or parameters of a function.

Usage: {{Optional_Inline}} or {{ReadOnlyInline}}. Example:

isCustomObject Read only

Indicates, if true, that the object is a custom one.

parameterX Optional

Blah blah blah…

Status and compatibility indicators

Inline indicators with no additional parameters


non-standard_inline inserts an in-line mark indicating the API has not been standardized and is not on a standards track.



  • Icon: Non-standard


experimental_inline inserts an in-line mark indicating the API is not widely implemented and may change in the future. For more information on the definition experimental, see the Experimental, deprecated, and obsolete documentation.



  • Icon: Experimental

Inline indicators that support specifying the technology


deprecated_inline inserts an in-line deprecated mark ( Deprecated ) to discourage the use of an API that is officially deprecated (or has been removed). For more information on the definition deprecated, see the Experimental, deprecated, and obsolete documentation.



  • Icon: Deprecated

Page or section header indicators

These templates have the same semantics as their inline counterparts described above. The templates should be placed directly underneath the main page title (or breadcrumb navigation if available) in the reference page. They can also be used to mark up a section on a page.

  • non-standard_header: {{Non-standard_Header}}

    Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

  • SeeCompatTable used on pages that document experimental features. Example: {{SeeCompatTable}}

    Experimental: This is an experimental technology
    Check the Browser compatibility table carefully before using this in production.

  • deprecated_header: {{Deprecated_Header}}

    Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

  • secureContext_header. Should be used on main pages like interface pages, API overview pages, and API entry points (e.g. but usually not on subpages like method and property pages. Example: {{SecureContext_Header}}

    Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

Indicating that a feature is available in web workers

The AvailableInWorkers macro inserts a localized note box indicating that a feature is available in a Web worker context. You can use the argument window_and_worker_except_service to indicate that a feature works in web workers except for service workers.


Note: This feature is available in Web Workers.

Note: This feature is available in Web Workers, except for Service Workers.

Browser compatibility and specification macros

The following macros are included on all reference pages, but are also supported by all page types:

{{Compat}} / {{Compat(<feature>)}} / {{Compat(<feature>, <depth>)}}

Generates a compatibility table for the feature passed as the parameter. If no parameter is included, it defaults to the features defined by browser-compat in the frontmatter. An optional depth parameter sets how deep sub features should be added to the table. The depth, if omitted, defaults to 1, meaning only the first level of sub feature data from BCD will be included.

{{Specifications}} / {{Specifications(<feature>)}}

Includes the specification for the feature specified in the parameter. If no parameter is passed, the specification listed is defined by the value for spec_urls in the frontmatter, if present, or from the specification listed in browser compatibility data defined by browser-compat in the frontmatter. The specification is rendered as an external link.

See also