Minecraft Wiki:Style guide

This article aims to provide a comprehensive style guide for all Minecraft Wiki articles to follow. There are often disputes over which style rule or formatting to use so an official style guide helps resolve these disputes and reach a consensus.

Although Wikipedia already provides a more general style guide, a more specific one is necessary for Minecraft-specific guidelines. As such, only guidelines pertaining to the Minecraft Wiki and its basic formatting rules are included here. If any contradiction arises, this page always has precedence over its subpages and the Wikipedia style guide.

Article titles should generally be written in singular form, except in-game features with plural names (e.g. "Boots").

Articles should follow a general naming format based on the type.

• An article about any feature with an in-game name should use the same capitalization as the name. For example, "Eye of Ender" is correct, since the eye of ender is called "Eye of Ender" in the game.
  • The title of an article about a game mechanic, not an individual feature or features in the game, should be written like a heading (see MCW:HEADING). For example, "Tutorials/Eye of ender farming" should not use the item name "Eye of Ender", since the article would not solely be about the eye of ender, and it should not have a convoluted name, like "Tutorials/Farm for eyes of ender in the end".
  • 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 title should be written like a heading.
  • If the feature does not have an in-game name, it should follow the same format as other articles of the same type. For example, the mob Spider Jockey"
  • If the article is about multiple similar features, the title should equally represent all the titles. For example, an article about wooden and iron doors would be called "Door". Also, the name should follow the same format as the names of those features. An article about doors made of wood would be called "Wooden Door" because wooden tools in the game use a similar naming convention.
  • If the feature has different names in Java and Bedrock Edition, the Java Edition name should be used.
    • If the Java Edition name would require a disambiguation but the Bedrock Edition name won't, the Bedrock Edition name should be used.
  • If the feature has no display name in any edition, the ID of the feature in Java Edition should be used.
    • If the feature has no display name in Java or Bedrock Edition, but does have a display name in some other edition, the display name from that edition should be the article's title.
    • If the feature doesn't exist in Java Edition, it should use the display name or ID in the most relevant edition it exists in.
• Articles about people should use their first name and last name rather than their Minecraft or Twitter/X handle.
• Tutorial articles should be prefixed with "Tutorials/" and should not contain "How to".
• If the article's type is unlisted, it should use the most relevant title in sentence case, not title case, unless it is a proper noun. This also applies to some non-article pages, such as category, template, and project pages.

This wiki's purpose is to document facts. Therefore, always avoid personal commentary, speculation, and unsourced information. Generally speaking, information does not require sources if they can directly be seen in-game or are otherwise obvious. Other information however, such as quotes from Mojang Studios employees and information that is not widely known, must be sourced with a proper reference. The {{citation needed}} template should be placed after any information that requires a source. Do not add content to an article without a proper source.

Articles in the main namespace 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."

To emphasize points, italics should be used, not bold or ALL CAPS.

Tutorial information should be present only in tutorial articles. This includes navigational features of blocks or textures. Tutorials may be linked from other articles if relevant though.

Keeping articles concise and up to date

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. 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. History information is good, but for clarity, it should be described in the chronological order in a single place: the History section of the article.

Future

Content added in future updates may be added to the article in the main content, provided the features are marked using {{Upcoming}} / {{OnlyUpcoming}}. Features that will be removed in a future update should be marked with {{Until}}. Changes to existing features should use {{OnlyUpcoming}} where possible, since it can be used inline. {{Upcoming}} should be used for major features or major changes to features. The feature, features, or changes marked by Upcoming can be put in a section of an article, if appropriate. 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 containing an upcoming feature releases, features marked with {{Until}} must either be moved to the history section or removed, and any usage of {{Upcoming}} / {{OnlyUpcoming}} may be removed.

Information about future updated should always be valid. Valid information 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 seriously. Some videos on the channel are clearly made as trailers or announcements for development versions that get released shortly afterwards, but this is not always 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.

Quotes

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.

Spelling

Pages on this wiki should use American English because this is the default localization used by Minecraft. The exception is if the in-game name is British English.

The differences between American and British spelling can be subtle. The following examples often arise:

• Words ending in "-or": "colour" should be "color", "behaviour" should be "behavior", "armour" should be "armor"
• Words ending in "-ter": "centre" should be "center", "metre" should be "meter"
• Direction-indicating words ending in "-ward": "towards" should be "toward", "forwards" should be "forward", "upwards" should be "upward" and so on
• Words without the "-st" affectation: "whilst" should be "while", "amongst" should be "among", "amidst" should be "amid"
• Words with "-z" suffixes: "organise", "analysing", and "realisation" should be "organize", "analyzing", and "realization", respectively
• Words ending in "-nse": "defence" should be "defense"
• Suffixes on words ending in "-l": "travelling" should be "traveling"
• Past tense verbs: "spelt" should be "spelled", "learnt" schould be "learned"

Capitalization

In-game items should be treated as common nouns and as such should not be capitalized, unless they start a new sentence. This includes fictional items, such as prismarine. Proper nouns, however, such as the Nether or the Overworld should always be capitalized.

Do not capitalize

In-game items

In-game items (weapons, armor, tools, objects, blocks, fictional items) are common nouns and should not be capitalized unless they start a new sentence.

Examples:

A conduit requires a prismarine frame in order to activate.

This mob uses a scatter crossbow.

To mine diamond ore, a player must use an iron pickaxe or better.

Structures and biomes

In-game structures and biome names should not be capitalized.

Examples:

Underground, there are randomly generated mineshafts.

A desert pyramid contains some rare loot.

Blazes spawn in nether fortresses.

In deep ocean biomes, monuments can generate.

A stronghold is home to an end portal.

Mobs

Any instance of a mob (including mini-boss mobs) should be treated as a common noun, except where the mob is referred to using a proper noun. If the word "the" is used before the mob name, it should not be capitalized unless it is at the beginning of the sentence.

Examples:

One of the most feared mobs is the ghast.

A cave spider can poison its prey.

The player has been referred to as Steve.

Edition adjectives and descriptors

"Experimental snapshot", "snapshot", "pre-release", and "release candidate" should not be capitalized, except in cases where they are capitalized in the game itself, in which case they should be capitalized only within the context of the name itself. "Pre-release" should always be hyphenated.

Minecraft Dungeons

In addition to the instances above, do not capitalize the names of unique items or hostile mob attacks.

Do capitalize

Enchantments

Enchantment names should always be capitalized.

Example:

In order to have ice drop an item, a tool enchanted with Silk Touch should be used.

Status effects

Status effect names should be capitalized, except where they are used as an adjective.

Examples:

Magma cream is required for a potion of Fire Resistance.

Wither skeletons may inflict Wither on the player.

An invisible spider may rarely spawn.

Editions

Editions should be capitalized only when used as nouns.

Development phases should be capitalized.

Examples:

Minecraft: Java Edition officially came out of Beta on November 18, 2011.

The rose, with an exclusive texture, was introduced in Pocket Edition v0.1.0 alpha.

Of all the editions of Minecraft, only the Pocket and Pi Editions have blue roses.

Game modes and difficulty

The name of game modes and difficulty should be capitalized.

Examples:

In Hardcore mode the game acts similar to Survival mode except the difficulty is permanently set to Hard, and you cannot respawn.

Minecraft Dungeons

Some features unique to Minecraft Dungeons are treated as proper nouns, similar to enchantments and status effects, so they should be capitalized. These features are:

• Ancient mobs and primary boss mobs
• Locations

Minecraft: Story Mode and Minecraft: Story Mode - Season Two

• In Minecraft: Story Mode and Minecraft: Story Mode - Season Two, given names of towns, cities, and villages should always be capitalized.
• Names of characters should always be capitalized.
• Given names of teams and groups should be capitalized if they're capitalized in-game.
• Names of events such as EnderCon should be capitalized only if they're capitalized in-game.
• Names of worlds and dimensions should be capitalized only if they're capitalized in-game.
• In rare cases in which the name has two variations, capitalized and not capitalized, the capitalized spelling takes preference.

Examples:

The wither storm destroyed the building at EnderCon.

Olivia is a friend of Jesse.

The fate of Build Club is unknown.

There is a llama statue in Champion City.

Section headings

• 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.
• For information on which sections should be in which order, see the Article layout section of this style guide.

Italics

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 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.

Images

Screenshots

• 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.

Captions

Image captions should not have periods at the end, unless the phrase is a full sentence.

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 rule applies to all pages. Artwork can be used elsewhere on the page, such as in galleries, but not as the infobox image.

Upscaling textures

Generally, textures should be uploaded as their original resolutions, and therefore should not be upscaled. The exceptions to this are item and effect icons, though original resolutions versions of these textures should still be provided via the gallery.

General guidelines

• Images should showcase an attribute of the article's topic.
  • Images should not show unintended strange or humorous behavior, such as mobs "sitting" on stairs.
  • Images should not have the sole purpose of showcasing a bug, instead report the bug on the official tracker.
  • Images showcasing usage of specific features as part of player builds should be avoided.
• Articles should have one image showcasing an individual attribute of the articles content. For example, a zombie wearing armor.
• Images should showcase the most up-to-date version of Minecraft available for the content. Outdated images are subject to removal or replacement with current versions.

Linking

For a complete guide to linking, please refer to Wikipedia's Manual of Style for links, although do note that some of the policies about linking listed there are different than many here.

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 if the links are directing them to different articles or not.

The guidelines for linking are:

• No more than 10 percent of the words in an article are contained in links.
• Unless it affects the sentence's wording and readability in a negative way, 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 using a suffix on the link, that is preferred. E.g. Using [[Creeper]]s instead of [[Creepers]] is desired.

Sprite links

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 can easily create clutter within text, and therefore:

• Sprite links should only be used 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:

Overworld trees

Wood type	Tree type	Forest biome
Oak	Oak	Forest
Birch	Birch	Birch Forest
Spruce	Spruce	Taiga
Jungle	Jungle	Jungle
Dark Oak	Dark Oak	Dark Forest
Acacia	Acacia	Savanna
Mangrove	Mangrove	Mangrove Swamp
Cherry	Cherry	Cherry Grove

Date formatting

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 DD, YYYY" format, e.g. "December 10, 2011". 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.

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

Coordinates

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 ×. 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. Further coordinate usage is under discussion.

Commands

Edition version names

Specific versions on specific editions of the game should always be written as an edition version name. This rule 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. For example, "1.2.0.9" would be titled "Bedrock Edition beta 1.2.0.9".

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".

File names should be consistent so they are easier to find. Files used in the infobox of articles should be titled with the exact name of the subject as seen ingame using en-US (when possible), and must be an isometric render. 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.

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]} and references^[1]
8. Applicable footer navboxes
9. DEFAULTSORT
10. Categories
11. Language interwikis

Be smart when adding a message box: too many boxes at the top of a page or a section is 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 on the page, for example in a relevant section or at the end.

Specific layouts

If an article does not contain a layout currently, one can be proposed on the 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