Wikipedia:Linter

This is an information page.

It is not a Wikipedia policy or guideline; rather, its purpose is to explain certain aspects of Wikipedia's norms, customs, technicalities, or practices. It may reflect varying levels of consensus.

Shortcut

WP:LINTWP:LINT

The Linter extension is a MediaWiki extension that aims to identify "lint": syntax errors in the code of Wikipedia pages. The lint in this case is broken and problematic markup on all wiki pages that cannot be fixed automatically by MediaWiki. The extension produces a list of these errors at Special:LintErrors, which editors and bots can consult to find pages that need attention. High-priority Linter issues require fixing as they may cause pages to display in undesirable fashion. The MediaWiki wiki help page describes 18 specific types of lint errors.

Background

A linter is software that helps an author or editor of a document (such as a wiki page or a programming file) see if there may be errors in the document. The extension does this for wiki pages: it helps identify whether a page displays as the author intended yesterday in some cases (for example, some image options are "linted" for), and helps identify whether a page displays as the author intended today, due to changes in how the MediaWiki system creates HTML from wikitext. Further reasons can be found at mw:Help:Extension:Linter § Why and what to fix.

List of lint errors

From Special:LintErrors. The database ids are defined in the MediaWiki source code.

High priority

Table tag that should be deleted (id 7)
Duplicate IDs (id 25)
Misnested tag with different rendering in HTML5 and HTML4 (id 12)
Miscellaneous issues (id 17)
Multiline table in list (id 16)
Multiple unclosed formatting tags (id 14)
Paragraph wrapping bug workaround (id 9)
Self-closed tags (id 6)
Extension tag with template parameter (id 27)
Old behaviour of link-wrapping font tags (id 13)
Whitespace parsing bug (id 10)
Unclosed quote in heading (id 15)

Medium priority

Low priority

Empty headings (id 26)
Missing end tag (id 4)
Missing end tag in heading (id 21)
Background color inline style rule exists without a corresponding text color (id 22)
Obsolete HTML tags (id 2)
Stripped tags (id 5)

Tracking only (not listed on Special page)

Large tables (buggy, not an error; for tracking only; not listed on Special page) (id 20)
fostered-transparent (buggy, not usually an error; for tracking only; not listed on Special page) (id 24)
missing-image-alt-text (not always an error; see WP:MOSALT: An image that is purely decorative (provides no information and serves only an aesthetic purpose) requires no alternative text.) (id 23)
pre-expansion (id 28)

How you can help

Editors (mostly WikiGnomes) are going around Wikipedia working to clean up lint errors, which are sorted by severity into one of three priority levels: high, medium, and low, which relate to how badly the error affects page display, or how much the page display changed when MediaWiki parsing changed. You are welcome to join in this effort. Here are some hints:

Each lint error page has a help link in the upper-right corner that links to a page with more information about that type of error.
Lint error pages are sorted approximately in the order of the most recently edited being listed last. Some error pages are sorted better than others.
Lint error pages are not necessarily complete. When a new lint error type is discovered and a page is made for it, or when the definition of a type of lint error is changed, that lint error page starts empty and is gradually filled by a process that can take several weeks or months.
Every page's page information details how many errors of each type of lint error that page has. This section is near the end and is omitted if there are no lint errors.
For each lint error, the count maxes out at 20 in any one page.
It is OK to edit other people's User and User talk pages, and other people's comments on talk pages; but if you do, please see Wikipedia:Talk page guidelines § Editing others' comments for guidance.
- Don't change the words of other editors.
- Try to preserve the appearance.
- It is OK to change the appearance in some cases if it preserves the original intent.
  - It is OK to fix a missing end tag, such as a <small> tag improperly closed with another <small> tag instead of </small>, even if this changes the appearance. This is especially true if the missing end tag affects anything beyond the scope of the comment in which it appears. If a user's comment in the middle of the page causes subsequent comments or sections to be indented wrong, or be bolded or italicized or in a different font, you should insert the missing end tag, even if the page has "always" been wrong.
    - Fixing such errors has become more urgent; after MediaWiki's July 2018 switch to a new linter package, many pages that used to look fine despite errors in them now show terrible appearance and accessibility problems, such as fonts becoming smaller and smaller (or larger and larger) the further down the page you scroll, due to successive unclosed sizing elements.
  - In a discussion about wiki or HTML markup, unclosed tags are sometimes used. For example, in a discussion about the <div> tag, the tag might not be surrounded by <nowiki> markup, so the <div> tag will be taken as markup with a missing end tag instead of simply displaying the tag. In cases like this, it is helpful to insert <nowiki>...</nowiki> around the unescaped markup, which changes the display, shows the intent of the original comment, and fixes the missing end tag or other errors resulting from the unescaped markup.
- In a discussion about errors, for example, "Why does the display get messed up when I use [some bad markup]", it's often best to leave the bad markup in place, since otherwise the discussion won't make any sense.
- Especially on User and User talk pages, try to minimize disruption by getting your fix right on the first try. "Show preview" is your friend.
  - By default, editing a base user talk page will trigger a notification to the user, which can be annoying and should not be done in large batches. To avoid this, use a flagged bot account, and also flag the edit as minor, which will bypass the "You have new messages" notification.
See also WP:HTML 5 § Obsolete elements and attributes for a list of invalid tags and attributes, which you can detect with CSS. See below.
Some Lint errors caused by user signatures and Template substitutions are present across a large number of pages. It is more efficient to fix such errors in a bot task rather than manual edits. You can use regex-based insource search to identify patterns of errors that can be fixed by bots.
If you find a lint error in an article, consider the possibility that the error was introduced by a recent edit that should be reverted. This is especially true for Table tag that should be deleted and Fostered content lint errors, where careless deletion of table end markup (|}) can cause either of these lint errors. The solution to a lint error may be to revert one or more edits.
Occasionally, large pages show up on lint error lists without there actually being any errors on the pages themselves. If there's nothing obviously wrong with a listed page, and page information, lintHint, and template expansion show no errors, it will often disappear from the list on its own after a while. Editors can usually expedite this by null editing the page in question.
The Duplicate IDs lint error in most cases arises from citation templates, where manually fixing is currently not possible.
The Background color inline style rule exists without a corresponding text color lint error, intended to improve dark mode compatibility, is intentionally ignored by lintHint. It is also limited, e.g. returning false positives when a color is properly set outside of the tag that contains the background color setting. In most cases, the flagged issue can be solved in another way, so it is usually best to ignore this error.
You can fix other errors not detected by the linter and lintHint, including those mentioned below in #Other errors.

Reports

Outstanding linter errors on enwiki via The Firefly Tools table – a chart with rows for the namespaces and columns for the type of lint error, with each cell in the chart listing the number of errors (maxed at 20 for each error type per article). This chart can help find a project of manageable size, or quickly check the number of lint errors of a certain type in a namespace, such as the Article namespace. This page is updated several times per hour.
Wikipedia:Linter/reports/Pages by Lint Errors (1000) – Covers pages in all namespaces that have the most lint errors. Note that the Linter error system tracks a maximum of 21 errors of any single type, so pages on this list may have more total errors than are shown in the report.
Wikipedia:Linter/reports/Articles by Lint Errors (0) – Covers articles (i.e. pages in the article namespace) that have the most lint errors.
Wikipedia:Linter/reports/Pages by Non-Font Lint Errors (1000) – Covers pages in all namespaces that have the most lint errors, but excluding pages with <font>...</font> tags.
Wikipedia:Linter/reports/IP user talk pages by Lint Errors (82) –
Wikipedia:Linter/reports/Protected pages by Lint Errors (346) – Protected pages that contain lint errors.
Wikipedia:Linter/reports/Wikipedia:Admin pages by Non-Font Lint Errors (449) – This report lists Administrators' Noticeboard pages with Linter errors other than font and tt tag errors. A combination of LintHint, the syntax highlighter, and Special:ExpandTemplates is often needed to track down all of the Linter errors in these complex pages.
Recent changes of "extraneous markup" tag.

Other useful pages

Linter error count progression

Linter error count progression
Date	Outstanding linter errors	Source
28 August 2018	24,083,947
17 June 2021	22,450,097
1 March 2022	15,349,584
25 March 2022	13,845,831
1 July 2022	11,116,651
3 November 2022	8,890,312
4 February 2023	7,994,445
13 February 2023	6,984,595
23 February 2023	5,998,634
5 March 2023	4,999,462
26 March 2023	3,996,924
28 December 2023	3,496,968
5 November 2024	2,999,906
26 December 2025	2,499,866
24 February 2026	1,999,893

Bots

Bots that are approved to run lint fixing tasks:

Active bots
Bot	Operator	Tasks	Lint fixes status (last 30 days)
User:DreamRimmer bot III	User:Max	Task 8 is approved to fix errors in MassMessages, including Linter errors.	Active (upon request)
User:Legobot	User:Legoktm	Task 41	Active
User:Qwerfjkl (bot)	User:Qwerfjkl	Tasks 27, 29, 31	Active
User:TenshiBot	User:Tenshi Hinanawi	Tasks 4, 5, 6, 12	Active
User:WikiCleanerBot	User:NicoV	Tasks 7, 10, 17, 22	Active
User:WOSlinkerBot	User:WOSlinker	Tasks 1, 2, 4, 7, 8, 9, 10, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24	Active

Inactive bots or tasks
Bot	Operator	Tasks
User:Ahechtbot	User:Ahecht	Tasks 1, 2, 3, 5
User:DannyS712 bot	User:DannyS712	Task 54
User:FrescoBot	User:Basilicofresco	Task 13
User:IznoBot	User:Izno	Task 1
User:John of Reading Bot	User:John of Reading	Task 4
User:MalnadachBot	User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ	Tasks 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12
User:MatrixBot	User:Matrix	Task 2
User:NihlusBOT	User:Nihlus	Tasks 2, 5, 10
User:PkbwcgsBot	User:Pkbwcgs	Tasks 17, 18
User:SheepLinterBot	User:Sheep8144402	Tasks 1, 2

Using the "fixed lint errors" tag

Some bots use the tag fixed lint errors which can be used to filter in the edit log or hide in your watchlist. Recent changes.

Bot operators using Pywikibot can apply the tag with page.save(summary='Fixing lint issues', tags=['fixed lint errors'])

For JavaScript, add the following:

// Add change tag
var form = document.getElementById('editform');
if (form && !form.wpChangeTags) {
    var tagInput = document.createElement('input');
    tagInput.type = 'hidden';
    tagInput.name = 'wpChangeTags';
    tagInput.value = 'fixed lint errors';
    form.appendChild(tagInput);
}

Tools

User JavaScript tool: lintHint

User:PerfektesChaos/js/lintHint has instructions for installing and using lintHint, a gadget coded in JavaScript that identifies lint errors in a document in the wiki editor.

You can run lintHint repeatedly in the same edit session to see if you fixed the errors and to relocalize the error pointers. Error pointers are relative to the top of the article, so if you correct errors from the bottom up, you won't need to run lintHint again to relocalize error pointers.

The lintHint tool does not expand relative links when the page is in editing mode. For example, in Portal:Science, {{/Header}} really means {{Portal:Science/Header}}, but lintHint does not do this. To get lintHint to work, you should expand the relative links so future users do not need to reencounter the same errors. You can also use Expand templates, and enter the page name in Context title and copy part or all of the page into Input wikitext. Then click OK and then press lintHint. Expand templates will often help lintHint localize and identify lint errors listed on Page information but that lintHint doesn't find on its own.

After editing, pages are rechecked for lint errors, usually within seconds, but in the past sometimes delayed for hours. If lintHint says you fixed one or more lint errors, you probably did fix them, even if page information and the specific lint errors page aren't updated yet. As noted, however, lintHint can't detect errors in unexpanded relative links.

User CSS tool: lint.css

You can easily employ user CSS to detect a lot of "linty" old HTML 4 code in pages as you read, if you're a WikiGnome who likes to do cleanup. See meta:User:SMcCandlish/lint.css for a sample CSS declaration that makes various deprecated cruft – like <tt>, <font>, <center>, and <strike> – turn pink so it sticks out like a sore thumb. You can customize as you like for your own Special:MyPage/common.css or meta:Special:MyPage/global.css, or follow the instructions at lint.css to @import (transclude) lint.css directly into your own user CSS at this or any other WMF wiki.

This CSS only detects no-longer-valid markup; it has no means of detecting other coding errors.

See here for another example.