The relevant api URLs, which LintHint fetches, are respectively:

• https://de.wikipedia.org/api/rest_v1/page/lint/Wikipedia:FilmFrauen%2FBerlinale-Edit-a-thon_2026
• https://en.wikipedia.org/api/rest_v1/page/lint/Wikipedia:Wikipedia_Signpost%2F2026-02-17%2FOpinion
• https://en.wikipedia.org/api/rest_v1/page/lint/Wikipedia:Reference_desk%2FArchives%2FScience%2F2012_September_24

This is what LintHint is reporting.

LintHint should be using

https://en.wikipedia.org/w/rest.php/v1/page/Wikipedia:Reference_desk%2FArchives%2FScience%2F2012_September_24/lint
etc

but the former should be routed there internally, so that's not the issue.

Locally, I see

λ (master) php bin/parse.php --wt2lint --page "Wikipedia:Reference_desk/Archives/Science/2012_September_24"
{"type":"night-mode-unaware-background-color","dsr":[999,1609,113,2],"templateInfo":null,"params":[]}

which agrees with the info action.

This appears to be a problem caused by a recent change, probably sometime in early 2026. Here are three recent threads (February 2026 and March 2026) related to these new discrepancies:

The switchover happened at the end of November in T384216 which seems too long ago? Maybe the MediaWiki-API-Platform-Team knows?

In If5a896acbc1153de6fab5ee69418204cb6834897, a LintErrorChecker is used instead of the linter tables for the latest revision, which gives some room for the discrepancy, but could also be a caching issue somewhere.

One workaround is to enable the improved syntax highlighting beta feature (CodeMirror 6) and enable the linting feature in CodeMirror preference dialog. It reports Parsoid lint errors consistent with the page information in my tests.

In T419596#11698377, @Bhsd wrote:

One workaround is to enable the improved syntax highlighting beta feature (CodeMirror 6) and enable the linting feature in CodeMirror preference dialog. It reports Parsoid lint errors consistent with the page information in my tests.

Have you actually tried that beta feature for fixing Linter errors? It has many problems that I identified with just a few clicks, making it essentially unusable for that purpose, at least for me.

In T419596#11700628, @Jonesey95 wrote:

Have you actually tried that beta feature for fixing Linter errors? It has many problems that I identified with just a few clicks, making it essentially unusable for that purpose, at least for me.

Of course I use it all the time. You should really try the linting feature and will see a status bar at the bottom of the editor. You can easily scroll to the next issue by clicking on the error/warning icons or pressing F8. There is no need to use lintHint any more with CodeMirror.

We have already submitted patches for all the issues you mention (T407203 and T418329).

We are all volunteers. Please be more polite.

If you are cleaning your wiki and visit all pages with a lint problem, on editing all “important” lint categories need to be highlighted (there are a few lint categories which should be ignored since they do not reflect real errors).

If on editing a lint error is caused, all authors should be reminded immediately that they would produce an entry in the project surveillance.

Therefore the lint selection needs to be a subset of an extended highlighting with more CodeMirror recommendations. Some neglegctable unwise lint categories could be dropped.

In T419596#11700686, @Bhsd wrote:

In T419596#11700628, @Jonesey95 wrote:

Have you actually tried that beta feature for fixing Linter errors? It has many problems that I identified with just a few clicks, making it essentially unusable for that purpose, at least for me.

Of course I use it all the time. You should really try the linting feature and will see a status bar at the bottom of the editor. You can easily scroll to the next issue by clicking on the error/warning icons or pressing F8. There is no need to use lintHint any more with CodeMirror.

We have already submitted patches for all the issues you mention (T407203 and T418329).

We are all volunteers. Please be more polite.

I tried the linting feature with the indicators of hundreds of issues at the bottom of the edit window, no list to show the errors that I care about and no way to disable the issues that do not matter to me (unlike the LintHint script). The syntax highlighter is unusable for me with the bugs that I listed. You recommended a tool and it doesn't work for me. I'm glad it works for you.

I try to be polite and just state facts. I have been burned too many times by half-built features that get pushed to production (e.g. Visual Editor, Vector 2022, Wikidata) and then are mostly abandoned, leaving highly active editors to fix or work around the problems that the new features create. If I come across as a bit frustrated, that frustration is well-earned.

Another example: At https://en.wikipedia.org/wiki/User_talk:Samuel_Blanning/February2006 LintHint shows an "empty heading" Linter error but Page information does not.

Another example: https://en.wikipedia.org/wiki/Template:Grade_B_colour shows a stripped span tag in LintHint, but there is no stripped span tag in the expanded wikitext and nothing shows in the Page information.

It is my impression that this problem is spreading, possibly as caches get refreshed. It is also my impression that this may be a bug in the Parsoid Linting parser. Just a guess, really, since I don't know how any of the background stuff works.

I have made a simplified example here:

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1343320742

The content of the page is:

{{#ifeq:{{NAMESPACE}}|User|<!--do nothing in User space-->|<div style="display:none;">}}

Since the page is in User space, there is no output, but LintHint incorrectly detects a missing /div end tag.

I hope this helps someone squish this growing bug.

Here's an incorrect finding of a "Link in Link" error by LintHint (checking the API):

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1343553706

The code is:

[https://theintercept.com/2019/04/18/robert-mueller-did-not-merely-reject-the-trumprussia-conspiracy-theories-he-obliterated-them/ {{xt|People know they were scammed, that their politics was drowned for years by a hoax}}]

Which expands to this valid, error-free code:

[https://theintercept.com/2019/04/18/robert-mueller-did-not-merely-reject-the-trumprussia-conspiracy-theories-he-obliterated-them/ <span class="example" style="font-family: Georgia, 'DejaVu Serif', serif; color: var(--color-content-added, #006400);" >People know they were scammed, that their politics was drowned for years by a hoax</span>]

Here's an opposite situation: LintHint reports no errors, either in Preview or on the rendered page, but Page information appear to correctly show a stripped /th tag:

https://en.wikipedia.org/w/index.php?title=User:Zairiii&oldid=1344785691

Here's one on Commons where LintHint shows no errors, the rendering is clearly broken, and Page information correctly shows the Linter errors:

https://commons.wikimedia.org/w/index.php?title=File:Nauka_p42ywania-46.png&oldid=931492763

When you copy the page to ExpandTemplates, LintHint correctly shows the Linter errors.

The fix for the Linter errors looks like this:

https://commons.wikimedia.org/w/index.php?title=File%3ANauka_p42ywania-39.png&diff=1185950714&oldid=1185950047

This is still happening. Today I found it at https://en.wikipedia.org/wiki/User:Uhai/Pages_without_short_descriptions_by_view_count (two stripped span tags reported via LintHint, but nothing on Page Information). Expanding the code that LintHint identifies shows no Linter errors.

Building off what @ABreault-WMF said, /page/{title}/lint is basically just a wrapper for a LintErrorChecker. The LintErrorChecker is given $content->getText(), which is retrieved via PageContentHelper, and ultimately calls Parsoid::wikitext2lint().

I notice that PageContentHelper sends a Cache-Control header with max-age 5. Seems fairly short, but I suppose worth noting. There are, of course, various other levels of caching that may be involved. I'm just mentioning this one because it appears directly in the REST handler.

PageContentHelper does the actual content retrieval via:

$content = $revision
  ->getSlot( $slotRole, RevisionRecord::FOR_THIS_USER, $this->authority )
  ->getContent()
  ->convert( CONTENT_MODEL_TEXT );

The parser and linter options are constructed and used here. The wikitext2lint() call looks like:

		return $this->parsoid->wikitext2lint(
			$this->pageConfigFactory->createFromParserOptions(
				ParserOptions::newFromAnon(),
				$title,
				$fakeRevision
			),
			$this->linterOptions( $disabled ),
			new ParserOutput()
		);

I know less about the Linter extension used on Page Information. Maybe others can comment there.

Change #1283086 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] [WIP] Provide PageIdentity as context for LintErrorChecker

https://gerrit.wikimedia.org/r/1283086

In T419596#11710729, @Jonesey95 wrote:

Here's an incorrect finding of a "Link in Link" error by LintHint (checking the API):

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1343553706

The code is:

[https://theintercept.com/2019/04/18/robert-mueller-did-not-merely-reject-the-trumprussia-conspiracy-theories-he-obliterated-them/ {{xt|People know they were scammed, that their politics was drowned for years by a hoax}}]

Which expands to this valid, error-free code:

[https://theintercept.com/2019/04/18/robert-mueller-did-not-merely-reject-the-trumprussia-conspiracy-theories-he-obliterated-them/ <span class="example" style="font-family: Georgia, 'DejaVu Serif', serif; color: var(--color-content-added, #006400);" >People know they were scammed, that their politics was drowned for years by a hoax</span>]

If you expand with the context title "Main Page" on https://en.wikipedia.org/wiki/Special:ExpandTemplates you get

[https://theintercept.com/2019/04/18/robert-mueller-did-not-merely-reject-the-trumprussia-conspiracy-theories-he-obliterated-them/ <span id="FormattingError" ></span><strong class="error">[[:Template:Example text]] is only for examples of style and formatting. Do not use it in actual articles.</strong>[[Category:Pages with incorrect formatting templates use]]]

which does have a link-in-link

In T419596#11707241, @Jonesey95 wrote:

I have made a simplified example here:

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1343320742

The content of the page is:

{{#ifeq:{{NAMESPACE}}|User|<!--do nothing in User space-->|<div style="display:none;">}}

Since the page is in User space, there is no output, but LintHint incorrectly detects a missing /div end tag.

I hope this helps someone squish this growing bug.

Thank you for providing this example, it clearly indicates that the page isn't being parsed with the right context title

I've put up a patch in T419596#11891680 that should fix the issue https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1283086

Change #1283086 merged by jenkins-bot:

[mediawiki/core@master] Provide page context for LintErrorChecker

https://gerrit.wikimedia.org/r/1283086

Change #1284687 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@wmf/1.47.0-wmf.1] Provide page context for LintErrorChecker

https://gerrit.wikimedia.org/r/1284687

Change #1284687 merged by jenkins-bot:

[mediawiki/core@wmf/1.47.0-wmf.1] Provide page context for LintErrorChecker

https://gerrit.wikimedia.org/r/1284687

Mentioned in SAL (#wikimedia-operations) [2026-05-07T20:07:34Z] <arlolra@deploy1003> Started scap sync-world: Backport for [[gerrit:1284687|Provide page context for LintErrorChecker (T419596)]], [[gerrit:1284771|Make email confirmation banner a standalone RL module (T425677)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-07T20:09:23Z] <arlolra@deploy1003> arlolra, mmartorana: Backport for [[gerrit:1284687|Provide page context for LintErrorChecker (T419596)]], [[gerrit:1284771|Make email confirmation banner a standalone RL module (T425677)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-05-07T20:14:52Z] <arlolra@deploy1003> Finished scap sync-world: Backport for [[gerrit:1284687|Provide page context for LintErrorChecker (T419596)]], [[gerrit:1284771|Make email confirmation banner a standalone RL module (T425677)]] (duration: 07m 18s)