Minecraft Wiki:Style guide

The Minecraft Wiki aims to provide its users with a comprehensive guide of writing conventions that all wiki articles should follow, to resolve disputes over which style rule or formatting to use, and reach a consensus.

The wiki stores information about the Minecraft franchise in a type of page called articles, which are the focus of this guide. Content other than articles belongs in different namespaces, such as files or templates.

Titles should generally follow a general naming format based on the type of title. Generally, titles should be written in singular form, except in-game features, franchise media, or merchandise with plural names (like "Boots").

If a Minecraft feature changes its name in a future version, it should use the current name as the title until the future version is released. After the release, the old title should become a redirect to the new name.

Articles about Minecraft features with display names

• Features with in-game display names should use the same name as in the game (like "Eye of Ender").
• Articles about multiple similar features should use a title that equally represents all of them. For example, "Door" represents all door types.
  • The title should follow the same format as the names of those features. For example, "Wooden Door" is similar to how wooden tools are named.
• If a feature display name is different between editions:
  • If it exists in Java Edition, the name in Java Edition should be used.
  • If it doesn't exist in Java Edition, it should use its display name in Bedrock Edition.
  • If it exists in neither Java Edition nor Bedrock Edition, it should use the display name from any other edition it may exist in.
• If a Java Edition name of a feature would require a disambiguation, but the Bedrock Edition name wouldn't, the latter should be used instead.
• The title should always be the US English name.

Articles about Minecraft features without display names

• Features without in-game display names should use their ID as the title, written in title case. For example, "Desert Well": the structure uses the ID desert_well, so the title should be "Desert Well" and not "Desert well".
• Game mechanics, not an individual feature or features in the game, should use sentence case (like "Mob spawning").
• If a feature has neither a display name nor an ID, it should follow the same naming as other similar articles (title case for structures, sentence case for mechanics or other).
• An article about a technical feature, such as NBT, should use its name as it appears in the game's code.
  • If the feature doesn't have a name in the code, then its article name should be written in sentence case if such form makes sense. Content whose technical name does not read clearly as a noun should not be modified from its technical form (for example, info_update).

Titles on other types of articles

• Tutorial articles should be in the Tutorial: namespace, should not contain "How to", and should be written in sentence case. For example, "Tutorial:Music disc farming" should not use the item name "Music Disc".
  • They also shouldn't use a complex or long name, like "Tutorial:Farm for music discs in the Overworld".
• Articles about people should use the most commonly used name in relation to Minecraft.
• Articles that are not about in-game features (like franchise-related media) should generally use the same name as the described subject matter, if any, and capitalized if the name is a proper noun. Otherwise, sentence case should be used.
  • This also applies to some non-article pages, such as category, template, and project pages.
• Articles about updates and game drops with no known final name should use a title of the format "Nth Drop <Year>", e.g. "Third Drop 2025", unless Mojang uses a placeholder name based on the theme of the update.

Titles with all caps text

• Any topic or feature with names stylized in all caps or its variants (e.g., small caps) for stylistic reasons should be written in title case or sentence case, as appropriate, following Wikipedia's all caps guidelines when applicable. Exceptions include acronyms and Roman numerals, which should retain their original capitalization.
• The original stylization of the name or title of an article's subject can be included in the lead section inside parentheses.

Articles should only contain information about Minecraft features, Minecraft spin-off game content, the Minecraft franchise, and generally information that can be confirmed to exist and is relevant to the article topic. Speculative, unproven, or misinformation is not allowed and should not be added to pages.

Tutorial information should be present only in tutorial articles. This includes guides to find certain features, blocks, or items, among other examples. However, tutorial articles may be linked from other articles if relevant.

For a more detailed view on the policies that describe the cases, whether an article should be made or not, see Minecraft Wiki:Notability.

This wiki's purpose is to document facts. Therefore, always avoid personal commentary, speculation, and unsourced information. Generally, information does not require sources if it can be directly seen in-game or from the source media or is otherwise obvious.

Other information, such as quotes from Mojang Studios employees or information that is not widely known, must be sourced with a proper reference (using <ref>[external link]</ref>, or similar, next to the paragraph that needs to be sourced). A full list of references should be shown in a References section using {{Reflist}}.

If there is information that may require a proper source to be fully analyzed (as in incomplete information), the {{citation needed}} template should be placed after it. Do not add this kind of content to an article without a proper source.

In the Minecraft game, features added in future updates may be added to an article, provided the feature is marked using {{In development}} at the start of the page or a section with the name of the new feature.

For changes to current features, use {{Upcoming}} (or {{InUpcoming}} where possible) in the sentence that describes the feature to include the new content. If the content is being removed from the game, use {{Until}} instead.

In some articles, it is helpful to put upcoming features and changes in a section called "Upcoming", and in other articles, the name of the new feature or changes might be more appropriate. Upcoming features must be noted as well in the {{HistoryTable}} section, using the proper upcoming header.

When the update contains an upcoming feature release, features marked with {{Until}} must either be moved to the history section or removed, and any usage of {{Upcoming}} or {{InUpcoming}} may be removed.

If the update changed the name of a feature that had been known by its old name for a considerable amount of time (multiple years), the intro lead of the article or section should include the previous name through an "otherwise known as [name]" presentation or similar (for instance, on Monster Room). This is the only case where historical information should be kept on the article content; other cases should not be kept.

Information about future updates should always be valid: it includes anything that is tested in development versions and anything that is officially announced by Mojang (a list of official websites and sources can be found on Help:Official sources).

• Hints from minecraft.net should be taken with a grain of salt, because the writers include a lot of jokes and like to make things sound more extravagant than they need to be.
• Much of the information from the series of the "Minecraft" YouTube channel also should not be taken completely seriously. Some videos on the channel are made as trailers or announcements for development versions that get released shortly afterward, though this may not always be the case.
• Mojang makes a lot of other posts on social media platforms, too. Keep in mind that some posts are designed to encourage speculation in the community.

In conclusion, do not add speculation to the content of articles on this wiki. Speculation might be appropriate for a talk page, but we don't want to confuse our readers with false information.

Articles sometimes need to use images (or other file types) to showcase certain behaviors present in the game. Thus, files generally should showcase an attribute of the article's topic when used on those pages.

Articles should have one image showcasing an individual attribute of the article content per section, only if needed. For example, a zombie wearing armor. Images should also showcase the most up-to-date version of Minecraft available for the content. Outdated images are subject to removal or replacement with current versions.

For guidelines on whether a file should be added or not to the wiki, see #Files. For the policy specific to whether videos should be included on the wiki, as well as managing their usage on the wiki, see Minecraft Wiki:Video policy.

Official artwork and logos

• Pursuant to a request from Microsoft, official artwork and logos are not allowed to be displayed inside an article's infobox.
  • The scope of disallowed images includes packaging artwork, update key arts, game logos, or any artwork produced by Mojang. It does not include any other images, such as block or mob renders and game screenshots.
  • This applies to all pages. Artwork can be used elsewhere on the page, such as in galleries, or below an infobox, but not as the infobox image.

Captions and alt text

• Thumbnail images ([[File:Example.png|thumb]]) should include a caption that describes their content, as well as alt text. For example, [[File:Example.png|thumb|A caption|alt=Alt text shown to screen readers]].
• Image captions should not have periods at the end, unless the phrase is a full sentence.

All quotes should be copied verbatim. Any additional content added within the quotation marks must be enclosed in square brackets. Terminal punctuation must go inside the quote only if it is in the original; otherwise, it must go outside. If the quote contains an error that was present in the original, add {{sic}} after that text to show readers that it is not a transcription mistake.

Articles written on the wiki should be written consistently. Thus, we give some advice to specify how to write content on our pages.

To emphasize points, italics should be used, not bold or ALL CAPS. Bold text should be used in the introductory lead section of an article to name a feature or topic.

Articles should always be written in the third-person perspective and without terms referential to the reader ("you", "your", etc.). The exception to this is tutorial pages, where, in most cases, "you" is the most appropriate pronoun to use when referring to the player.

Try not to use abbreviations of words, either. For instance, sentences like "You shouldn't come close to creepers because they'll explode and kill you." should be written as "A player can be killed by approaching a creeper close enough to cause it to explode."

All content on our articles should be referred to solely through in-game or official names, when applicable. This means that all content should be named and referred to using the title of the article that describes it.

Unless there are unique names present in-game, baby mobs are not to be referred to by real-world animal equivalent names (such as "cub" or "kit" for a baby fox) and should be referred to only as a "Baby" of whatever the mob in question is. The only exceptions to this are terms that Mojang has coined for creatures unique to Minecraft and regularly uses, such as "gurgle" for a baby drowned or "ghastling" for a baby happy ghast. An applicable citation must be provided when this is the case.

Pages on this wiki should use American English because this is the default localization used by Minecraft. Exceptions are when the in-game name is British English or when British spelling is used inside quotations.

The differences between American and British spelling can be subtle, typically in how the word ends. The following examples often arise:

• Words ending in "-our": "colour" should be "color", "behaviour" should be "behavior", "armour" should be "armor"
• Words ending in "-tre": "centre" should be "center", "metre" should be "meter"
• Direction indicators ending in "-wards": "towards" should be "toward", "forwards" should be "forward", "upwards" should be "upward", and so on
• Words with the "-st" affectation: "whilst" should be "while", "amongst" should be "among", "amidst" should be "amid"
• Words with "-ise" or "yse" suffixes: "organise", "analysing", and "realisation" should be "organize", "analyzing", and "realization", respectively
• Words ending in "-nce": "defence" should be "defense"
• Verbs ending in "-ling": "travelling" should be "traveling"
• Verbs ending with "t": "spelt" should be "spelled", "learnt" should be "learned", "burnt" should be "burned"

Content on the wiki in prose should be written differently from an article title. Specific capitalization guidelines apply to article content to make them follow consistency across the wiki.

The following tables will show what should and should not be capitalized:

When listing three or more items in prose, serial commas should be used after the second-to-last item before the conjunction (and, or, nor); e.g., "A, B, and C", not "A, B and C". This practice can prevent ambiguity. However, a serial comma should not be added if including it introduces more ambiguity than omitting it; refer to Wikipedia's Manual of Style for examples and guidelines.

Article main sections should start with level 2 headings (== Heading ==) and increase by one for subsections. Never use a level 1 heading (= Heading =); this is reserved for the article title.

• Follow sentence style capitalization, not title style, so only the first letter of the heading and proper nouns are capitalized.
• Headings should not have links or templates in them; links should be placed underneath, such as in a {{Main}} template.
• Although not required, having one space between sections and one space between the equal signs and the section name improves readability.
• Place any hatnotes and images immediately under the section heading, and then a space after those before the section content.
• Do not add blank sections unless tagged with {{empty section}} to request prompt expansion.
• Sections that take the form of groupings (e.g., 'Additions') should be in plural form, even when there is only one item in the section.

For information on which sections should be in which order, see the Article layout section of this style guide.

Text inside table heading cells should use sentence capitalization just like article section headings. Unlike section headings, however, table headings may include sprites and links.

Pseudo headings should use bold ('''Heading''') to highlight headings which aren't important enough to use a section heading.

• Follow sentence style capitalization, not title style, so only the first letter of the heading and proper nouns are capitalized.
• Pseudo headings may have links, images, or templates in them.
• Do not use ; for pseudo-headings, as that can cause accessibility issues, unless it is used for a description list.
• Do not use <small> for subheadings.

[Article lead here]
== Section ==
=== Sub-section ===
'''Pseudo-heading'''
* A bullet list
== Section ==
=== Sub-section ===
==== Sub-sub-section ====
; A term followed by
: at least one definition or at least one description list item
: and additional optional items, forming a list

[Article lead here]
== Section ==
=== Sub-section ===
; Pseudo-heading
* A bullet list
== Section ==
=== Sub-section ===
<small>== Sub-sub-section ==</small>

Any instance of "Minecraft " should be in italics. Any instance of the name of a video game should also be in italics. For instance: "Team Fortress 2".

Official Minecraft edition names used as subtitles of the game should be in italics. This applies (but is not limited) to:

• Java Edition
• Bedrock Edition
• Minecraft Education

Italics should not be used for unofficial edition names, such as "Legacy Console Edition".

Additionally, if an edition name is also referring to a specific version, it should not be in italics. For instance: "Java Edition 1.16" should not be in italics, whereas "Java Edition" should.

In hatnotes, where text is italicized by default, text that would otherwise be italicized should instead be de-italicized. For example:

Episode titles from other Minecraft spin-off games, such as Minecraft: Story Mode, should also be italicized. This helps avoid overuse of quotation marks and prevents confusion with similarly named subjects, such as the group "Order of the Stone".

The Minecraft Wiki is an international community. That is a good thing in general, but it makes a problem for numeric abbreviations of dates, such as "12/10/11": while most countries abbreviate dates as day/month/year, some Asian countries use year/month/day, and the US uses month/day/year.

So the above date could represent any of three different dates. To avoid this problem, most dates should be written in "Month D, YYYY" format, e.g. "December 10, 2011" or "May 4, 2012". Do not use superscripts or suffixes such as "April 23^rd" or "4th of May".

If a numeric or terse date is needed (such as in a table), then use YYYY-MM-DD, always with 2 digits for month and day (e.g., 2011-12-10 or 2012-05-04). Besides being the ISO standard, dates in this format naturally sort properly, say if the table column is later made sortable.

For similar reasons, all times should be written using UTC in the 24-hour format, such as "17:00 UTC", for combined date times such as "December 10, 2011, at 17:00 UTC". For sorting, date times should also follow the ISO standard like "2012-05-04T17:00Z".

Try to avoid seasons for dates such as "Summer 2021" or "Fall 2022" as the northern and southern hemispheres have opposite seasons. Instead, use phrases like "Mid-2021" or "Late 2022".

Single in-game coordinates should be capitalized and unspaced ("Y=1" instead of "y=1" or "y = 1"). Volumes should be in the order X, Y, Z, with each item separated only by a multiplication sign "×", which is available in the "Special characters/Symbols" group in the source editor, or use the HTML entity ×. Do not use the letter "x" in place of the multiplication sign.

For example, "4×3×2" is an area that is 4 blocks wide along the X axis, 3 along the Y axis (vertical), and 2 along the Z axis.

Specific versions on specific editions of the game should always be written as an edition version name. This applies to article titles, paragraphs, lists, and trivia sections.

Versions of Java Edition should be prefixed with "Java Edition" (e.g. Java Edition 1.8).

Pocket Edition versions should be prefixed with "Pocket Edition". For example, the update known as "v0.9.0 alpha" in-game would be titled "Pocket Edition v0.9.0 alpha".

• Pocket Edition Alpha development builds should first contain the parent version title, then the lowercase word "build" followed by the build number. For example, build 2 for "0.9.0" would be titled "Pocket Edition v0.9.0 alpha build 2".
• Pocket Edition development builds should first contain the lowercase word "alpha" followed by the version number. For example, "1.1.0.1" would be titled "Pocket Edition alpha 1.1.0.1".

Bedrock Edition versions should be prefixed with "Bedrock Edition". For example, the update "1.2.1" would be titled "Bedrock Edition 1.2.1".

• Bedrock Edition development builds should first contain the lowercase word "beta" followed by the version number, unless it was ever released under Minecraft Preview, in which case it should instead contain the uppercase word "Preview" followed by the version number. For example, "1.2.0.9" would be titled "Bedrock Edition beta 1.2.0.9".
• Bedrock Edition versions released with different version numbers on different platforms should use the lowest version number it was released as, with other version numbers being redirected to that title. For example, the initial release of The Wild Update for Bedrock Edition, which released as 1.19.0 on most platforms but released as 1.19.1 on Nintendo Switch, should be titled "Bedrock Edition 1.19.0".

Other versions should be prefixed with the edition. For example, the update "1.0.27" for Education Edition would be titled "Education Edition 1.0.27".

The name of the edition (e.g. "Java Edition") when part of a version name should not be italicized.

The use of links is a difficult balance between providing readers enough useful links to allow them to "wander through" articles and excessive linking that can distract them from their reading flow.

Underlinking can cause the reader to become frustrated because questions may arise about the article's contents, which can be resolved only by using the search option or other sources for clarification, interrupting and distracting the reader.

Overlinking may distract the reader because links are usually colored differently, causing the eye to shift focus constantly. Additionally, if the same word is linked multiple times in the same paragraph, it can cause the reader to question whether the links are directing them to different articles or not.

The guidelines for linking are:

• Links should not be excessively added in articles; for example, a sentence with every other word as a link is likely to be overlinked. However, links should still be present in articles.
• If it affects the sentence's wording and readability negatively, two links should not be next to each other in the text so that it looks like one link.
• Links for any single term should not be excessively repeated in the same article. Excessive linking is defined as linking the same term multiple times within a portion of text that can fit on a typical viewer's screen. Remember, the purpose of links is to direct the reader to a new spot at the point(s) where the reader is most likely to take a temporary detour due to needing more information.
• Duplicating an important link distant from a previous occurrence in an article may well be appropriate. If an important term appears many times in a long article, but is linked only once at the beginning of the article, it may actually be underlinked. Indeed, readers who jump directly to a subsection of interest must still be able to find a link. But take care in fixing such problems; the distance between duplicate links is an editor's preference; however, if in doubt, duplicate the term further down the article.

Linking to a redirect is preferred over using a piped link except in templates and other pages that are transcluded. When a piped link is unavoidable, it should not point to a redirect. If a redirect can be avoided by using a suffix on the link, that is preferred. E.g., use [[Creeper]]s instead of [[Creepers]].

When listing in-game features such as blocks and items, it is common to use a sprite link template, which displays a small image before a link. Sprite links can be useful for illustrating subjects, but create clutter within text. Therefore:

• Use sprite links only in non-sentence lists. They should not be used in prose; instead, the regular link format should be used.

For example, the following use of sprite links is incorrect:

Whereas, for example, the following uses of sprite links are correct:

For the sake of consistency, all articles of a specific type should follow a general layout.

1. Hatnotes (i.e. notes that belong at the very top of an article page)
2. Message boxes
3. Infoboxes
4. Introduction with a general description
5. Article body (multiple sections; see § Specific layouts below)
6. See also
7. Notes^{[note 1]}, then references^[1]
8. External links, if applicable
9. Applicable footer navboxes
10. DEFAULTSORT
11. Categories
12. Language interwikis

Be smart when adding a message box: too many boxes at the top of a page or a section are not useful, and they can clutter the page descriptions in search results. If there is already one, move the ones that are not necessary for the reader lower position on the page, for example, a relevant section or at the end. Similarly, any quote should not be placed at the top of the page, as it adds to visual clutter and distracts from the purpose of the introduction. Additionally, the introduction should be descriptive, informative, and long enough to prevent the article of templates like infoboxes from being picked up by search engines.

If an article does not contain a layout currently, one can be proposed on the style guide's talk page; otherwise, attempt to use a layout that follows a similar style to an existing layout. Current article layouts include:

• Features
• Redstone
• Blueprints
• Versions
• Commands
• Story Mode articles
• Dungeons articles

In short, articles should contain only information that is up to date, i.e., implemented in the latest full version of the game. Anything that is outdated should be moved to the History section of the article. When something changes, note the change in the History section and remove the outdated information from other sections of the article (except historical names from the intro lead section if they were used to name a feature for many months or years).

It is unnecessary to mention when a particular feature was implemented; this is once again reserved for the History section of the article. Sentences such as "Trading, which was implemented in 1.3.1, is a feature that allows players to exchange emeralds (previously rubies) for other items." should be written as "Trading is a feature that allows players to exchange emeralds for other items."

Here's an example of how to not write a good article. It uses a previous version of the Log article, which at the time was called Wood. This is the full introduction. Highlighted in yellow is the redundant information, and in pink the history information.

The issue with this is that old information is scattered with new information. The introduction should state the current description of the block with the current release. Historical information is good, but for clarity, it should be described in chronological order in a single place: the History section of the article.

Files, which are stored in the File: namespace, should not have unintelligible names or generic names (e.g. "Screenshot.png", "2024-06-25_17.53.26.png", "IMG_5478.jpg", etc.). Instead, they should follow a consistent naming so they are easier to find.

• Files used in the article body content should use capitalized names of an item, block or entity on their name (for Minecraft game content), but lowercase words for everything else. For example, File:Piglin Brute zombified.png.
• Files should not show unintended, strange, or humorous behavior, such as mobs "sitting" on stairs.
• Files should not have the sole purpose of showcasing a bug (except files intended to be used on tutorial pages that are marked with {{Uses bug}}).
• Files showcasing the usage of specific features as part of player builds should be avoided.
• Files used in the infobox of articles should be titled with the exact name of the subject as seen in-game using en-US (when possible), and must be an isometric render, unless they are for version infoboxes.

• Screenshots must use vanilla textures and UI.
• Screenshots that use custom textures or resource packs, UI mods, and other custom content are generally not allowed, with the following exceptions:
  • Historical images of missing versions,
  • Hiding UI elements for the purpose of improving clarity of the image subject,
  • In cases where a resource pack is necessary, in which case the caption should mention the modification; for example, an image illustrating a retextured cow would have its caption make it clear that the cow has been retextured using a resource pack.
• Screenshots of biomes must not be isometric.

• Generally, textures should be uploaded at their original resolutions, and therefore should not be upscaled.
  • The exceptions to this are item and effect icons, though original resolution versions of these textures should still be provided via the Gallery section of an article.

Old revisions of files should take the format of "Subject JEX BEY", where X and Y are the revision numbers for Java Edition and Bedrock Edition, respectively.

• This number is incremented each time the texture is updated in-game (e.g., not in teaser images). "Subject" should redirect to the most recent revision.
• If the current textures for Java Edition and Bedrock Edition differ, "Subject" redirects to the Java Edition texture, while "Subject BE" redirects to the Bedrock Edition texture.
• Textures added in snapshots should follow this naming convention, though "Subject" should not redirect to the texture until it is included in a full release.

For example, the texture files for cobblestone would go as follows:

• "Cobblestone JE1.png"
• "Cobblestone JE2 BE1.png"
• "Cobblestone JE3 BE2.png"
• "Cobblestone JE4.png"
• "Cobblestone JE5 BE3.png"
  • "Cobblestone.png" redirects here.

The "Subject JEX BEY" files should be used in places where the texture shouldn't change if the texture is updated, such as history sections and version guides. The "Subject" files should be used in places where the texture should always be up to date, such as infoboxes.

Files that pertain to any of the provided list of Minecraft spin-off media should include an abbreviation prefix in their file name.