A Better Way to See Errors in VS Code with Error Lens

Mar 3, 2026 · 3 min read

A Better Way to See Errors in VS Code with Error Lens

You’re writing a React component, ESLint flags a problem, and you have no idea until you glance down at the status bar — or worse, until the build fails. VS Code’s default error display relies on squiggly underlines and the Problems panel, both of which are easy to miss during fast-paced coding. Error Lens fixes that by bringing diagnostic messages directly into your editor view, on the line where the problem lives.

Here’s what it does, how it works, and what to keep in mind before you install it.

Key Takeaways

Error Lens displays diagnostic messages inline, right at the end of the offending line, so you catch issues without hovering or checking the Problems panel.
It doesn’t generate its own diagnostics — it surfaces what your language server, TypeScript compiler, ESLint, or other tools already report.
You can fine-tune visibility by filtering diagnostic levels, using cursor-follow mode, adding a render delay, and excluding files or messages by pattern.
Start with a minimal configuration showing only errors and warnings, then expand as you get comfortable.

What VS Code Error Lens Actually Does

Error Lens is a VS Code extension that improves error visibility by displaying diagnostic messages inline — right at the end of the offending line — instead of hiding them behind hover tooltips or the Problems panel.

When a language server or linter reports a problem, Error Lens:

Highlights the entire line with a color-coded background (red for errors, yellow for warnings, blue for info)
Appends the diagnostic message as text at the end of that line
Shows icons in the gutter alongside your line numbers (optional)
Surfaces a summary in the status bar (optional)

The key thing to understand: Error Lens doesn’t generate diagnostics on its own. It surfaces what your language server, TypeScript compiler, ESLint, or other linting tools already report. If a tool isn’t flagging an issue, Error Lens won’t show one either.

Why VS Code Inline Errors Matter for Frontend Workflows

Frontend development moves fast. You’re juggling TypeScript types, ESLint rules, CSS-in-JS, and component props — often across multiple files at once. The default VS Code experience asks you to either hover over underlines or keep one eye on the Problems panel. Neither is ideal when you’re in flow.

With VS Code inline errors visible directly in the editor, you notice problems the moment they appear. A mistyped prop name, a missing dependency in a useEffect, an unused import flagged by ESLint — all of it shows up immediately, in context, without breaking your focus to look elsewhere.

This tighter feedback loop is where Error Lens earns its place in a frontend workflow.

Configurable Diagnostic Levels and Display Options

Error Lens gives you control over what gets shown and how. The errorLens.enabledDiagnosticLevels setting accepts any combination of "error", "warning", "info", and "hint". If hint-level messages clutter your screen, you can drop them from the list entirely.

A few settings worth knowing:

{
  "errorLens.enabledDiagnosticLevels": ["error", "warning"],
  "errorLens.messageBackgroundMode": "message",
  "errorLens.followCursor": "activeLine",
  "errorLens.delay": 500
}

messageBackgroundMode controls whether the full line or just the message text gets highlighted. Setting it to "message" reduces visual noise significantly.
followCursor set to "activeLine" shows inline messages only for the line your cursor is on — a good option if you find full-file highlighting overwhelming.
delay adds a pause (in milliseconds) before decorations appear, which helps on large files where constant re-rendering can feel distracting.

You can also exclude specific files using glob patterns with errorLens.excludePatterns, or suppress diagnostics from specific tools using errorLens.excludeBySource.

Better Error Visibility Without the Noise

The most common complaint about the Error Lens extension for VS Code is information overload — especially on files with many existing warnings. The fix isn’t to uninstall it; it’s to tune it.

Start with errors and warnings only. Use "followCursor": "activeLine" if the full-file view is too much. Gradually expand what you show as you get comfortable. Most developers land on a configuration that feels natural within a day or two.

Conclusion

VS Code’s built-in diagnostics are functional but passive. Error Lens makes them active — putting the message where your eyes already are. For frontend developers who want faster, clearer feedback from ESLint, TypeScript, and other language tools, it’s one of the most practical extensions you can add to your setup.

Install it from the VS Code Marketplace, leave the defaults for a day, then adjust from there.

FAQs

Error Lens adds decorations to the editor but does not run any analysis itself. It reads diagnostics already produced by your language server or linter. On most machines the performance impact is negligible. If you notice lag on very large files, increase the delay setting or use followCursor activeLine mode to limit how many decorations render at once.

Yes. Error Lens works with any tool that reports diagnostics through the VS Code language server protocol. That includes TypeScript, Stylelint, Pylint, Rust Analyzer, and many others. If a diagnostic appears in the Problems panel, Error Lens can display it inline.

Use the errorLens.excludeBySource setting to filter out diagnostics from specific sources, or errorLens.excludePatterns with glob patterns to skip entire files or folders. You can also limit visible severity levels through errorLens.enabledDiagnosticLevels to show only errors and warnings.

The Problems panel lists all diagnostics in one place but requires you to shift focus away from your code. Error Lens keeps you in context by showing the message on the exact line where the issue occurs. Many developers use both together, relying on Error Lens for immediate awareness and the Problems panel for a project-wide overview.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.