What Is a Linter?
A linter is a tool that automatically scans source code for errors, bugs, style problems, and risky patterns before the code runs. It reads your code against a set of rules and flags anything suspicious, from an undefined variable to inconsistent formatting, often as you type in the editor. Linters keep a codebase consistent, catch mistakes early, and enforce team conventions without manual review. Popular examples include ESLint for JavaScript and Stylelint for CSS. The name comes from an early Unix tool called lint that flagged flaws in C code.
- What it does
- Automatically flags code errors, risky patterns, and style violations
- Common linters
- ESLint for JavaScript, Stylelint for CSS, plus framework rule sets
- Origin
- Named after lint, a 1978 Unix tool that flagged flaws in C code (Bell Labs)
- Runs where
- In the editor as you type, in the build step, and in continuous integration
- Rules are shared
- A config file lets a whole team enforce one standard (ESLint docs)
- Versus a formatter
- Formatters fix layout; linters also catch logic and correctness risks
What a linter does #
A linter is an automated code-quality tool that reads your source code and reports problems without running it. Think of it as a tireless proofreader for code: it checks each line against a set of rules and flags anything that looks wrong, risky, or inconsistent. That includes genuine bugs like using a variable that was never defined, stylistic issues like mixing quote styles, and patterns known to cause trouble later. Many linters run live inside the code editor, underlining problems as the developer types, so mistakes are caught within seconds rather than after deployment. Others run during the build or on a shared server before code is merged. The point is to catch and fix issues at the cheapest possible moment, long before they reach a live site and affect customers. Linters are standard equipment in professional development. For a business, they are one reason a professionally built site tends to have fewer avoidable bugs; our /services/web-app-development process treats linting as a baseline, not an optional extra.
Where the term linter comes from #
The name traces back to a program called lint, written by Stephen Johnson at Bell Labs in 1978 to analyze C source code. It flagged constructs that were technically legal but likely to be bugs, things the compiler would accept but a careful programmer would question. The name itself is a metaphor: like the bits of fluff and fibre a clothes dryer's lint trap collects, the tool gathered the small, undesirable specks in code that you want to clear away. The idea proved so useful that linting spread far beyond C, and today nearly every programming language has its own linters. In web development, the term is everywhere. Understanding the origin helps demystify the jargon: a linter is simply a lint-picker for code, catching the small flaws that accumulate in any real project. Our /wiki library explains related developer tooling in the same plain terms, so words like linter, transpiler, and formatter stop sounding like a foreign language when a developer uses them.
What linters actually catch #
Linters catch a broad range of issues that fall into a few groups. First are correctness problems: undefined variables, unreachable code, comparing values in ways that produce surprising results, or forgetting to handle a returned value. These are the closest thing to genuine bugs a linter can spot without running the code. Second are stylistic and consistency issues: indentation, quote marks, spacing, naming conventions, and formatting that, while not breaking anything, make a codebase harder to read when they vary from file to file. Third, many linters include rules that flag security-sensitive or performance-risky patterns, nudging developers away from known pitfalls. You choose which rules apply, so a team can be strict or lenient as suits them. The value is consistency and early warning: a linter never gets tired, never overlooks a rule, and treats every file the same. For a business, that translates into steadier quality. If your current site is buggy or inconsistent, our /services/website-rescue work often finds a codebase that never had linting in place.
Linter versus formatter #
Linters are frequently paired with formatters, and the two are easy to confuse. A formatter, such as Prettier, focuses purely on how code looks: indentation, line length, spacing, and where line breaks fall. It rewrites your code automatically into a consistent layout without judging its correctness. A linter goes further, examining not just appearance but meaning, catching logic problems, risky patterns, and rule violations a formatter would ignore. In practice, teams often use both: the formatter handles layout automatically so nobody argues about spacing, and the linter watches for substantive issues. Some linter rules overlap with formatting, but the modern convention is to let the formatter own layout and the linter own correctness and best practices. Neither replaces human code review, but together they remove a huge amount of tedious nitpicking and let reviewers focus on real design questions. This separation of duties is a small example of the disciplined workflow behind a well-built site, the kind of quality control our /services/web-app-development page describes in more detail.
A rule catching a common mistake #
A linter flags problems like an unused variable or a loose equality check, often before the code is ever run.
// ESLint would flag two issues here:
let count = 5; // 'count' is assigned but never used (no-unused-vars)
if (userId == null) { // Loose == can behave unexpectedly (eqeqeq)
return;
}
// Cleaner version the linter accepts:
if (userId === null || userId === undefined) {
return;
}How linting fits the workflow #
Linting shows up at several points in a professional workflow, each catching problems a little later than the last. The earliest is in the code editor itself, where a linter plugin underlines issues as the developer types, giving instant feedback. Next is the local build or a pre-commit check, which can block obviously broken code from even being saved into version control. Finally, in continuous integration, the linter runs automatically on a shared server whenever code is proposed for merging, so problems are caught before they reach the main codebase or a live site. Many teams configure the linter to fail the build if serious rules are broken, making clean code a requirement rather than a suggestion. This layered approach means a mistake has several chances to be caught cheaply. It is a core part of shipping changes safely, closely tied to the pull-request review process. Our /services/care-plans include this kind of disciplined pipeline, so ongoing changes to your site stay consistent and low-risk over time.
Why linting improves a codebase #
The benefits of linting compound over time, especially on a site maintained by more than one person. Consistency is the most obvious: with a shared configuration file, every developer's code follows the same conventions, so the codebase reads as though one careful author wrote it. That consistency makes changes faster and safer, because anyone can pick up any file without deciphering a personal style. Early error-catching is the second benefit: bugs found by a linter in seconds would otherwise cost far more to diagnose after they reach production and affect real customers. Third, linting encodes team knowledge into rules, so lessons learned from past mistakes automatically guide future code. It also lowers the burden on human reviewers, who can focus on architecture instead of spacing. None of this replaces skilled developers, but it makes good ones more effective and keeps standards from slipping under deadline pressure. For a business, that means a more reliable, maintainable site, which is exactly what our /free-website-audit checks for beneath the surface.
What linting means for your business #
You will never run a linter yourself, but its presence or absence quietly shapes your site's quality. A codebase built with linting tends to have fewer avoidable bugs, more consistent structure, and lower maintenance cost, because problems were caught early and the code reads cleanly. A codebase built without it often accumulates inconsistencies and hidden defects that surface as strange behavior later, and it becomes harder and pricier for a new developer to work on safely. When you hire someone to build or maintain a site, asking whether they use linting and automated checks is a fair, revealing question; a professional will say yes without hesitation. If you have inherited a site that behaves erratically or is expensive to change, poor or absent tooling is a common root cause. Our /services/website-rescue work frequently starts by introducing linting and automated checks to a neglected project, which immediately raises the floor on quality and makes every future change safer and cheaper to ship.
The bottom line on linters #
A linter is an automated tool that scans source code for errors, risky patterns, and style inconsistencies, flagging them before the code runs and often as the developer types. Named after a 1978 Unix tool, linters now exist for nearly every language; ESLint and Stylelint are the web's most common. They differ from formatters, which only fix layout, and they work alongside human review rather than replacing it. Running in the editor, the build, and continuous integration, a linter catches mistakes at the cheapest possible moment and keeps a whole team writing consistent code. For a business, linting is a quiet marker of professional quality that lowers bugs and long-term maintenance cost. You do not manage it; you just benefit from working with developers who use it. If your site is buggy or costly to change, our /services/website-rescue page explains how better tooling turns that around, and /contact reaches someone who can help.
FAQ
What does a linter do?
A linter automatically reads your source code and reports errors, risky patterns, and style inconsistencies without running the code. It checks each line against a set of rules and flags problems, often as the developer types. This catches mistakes early, keeps a codebase consistent, and enforces team conventions without slow manual review.
What is the difference between a linter and a formatter?
A formatter, like Prettier, only changes how code looks, fixing indentation, spacing, and line breaks automatically. A linter goes further, examining meaning to catch logic problems, risky patterns, and rule violations a formatter ignores. Teams often use both: the formatter owns layout, and the linter owns correctness and best practices.
What is the most popular linter?
For JavaScript and TypeScript, ESLint is by far the most widely used linter, with a huge library of configurable rules and plugins. For CSS, Stylelint fills the same role. Many frameworks ship their own recommended rule sets on top. Which you use depends on the languages and tools in your project.
Where does the word linter come from?
It comes from a 1978 Unix program called lint, written at Bell Labs to flag suspicious constructs in C code that the compiler would accept but were likely bugs. The name evokes the lint a dryer trap collects: small, unwanted specks you clear away. The concept later spread to nearly every language.
Do linters catch security problems?
Some do, partly. Many linters include rules that flag security-sensitive or risky patterns, nudging developers away from known pitfalls. However, a linter is not a full security scanner and cannot catch every vulnerability. It complements, rather than replaces, dedicated testing like our /services/website-security work provides for broader protection.
Should my website use a linter?
If a developer builds or maintains custom code for your site, yes. Linting catches bugs early, keeps the codebase consistent, and lowers long-term maintenance cost, all with no downside once configured. For a simple template site you edit through a dashboard, you would not manage a linter yourself, but the platform's developers rely on similar tools.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?