LWC debugging issues? Troubleshooting Lightning Debug Mode

You ticked "Lightning Debug Mode" in your user settings, opened the browser dev tools, and got nothing you expected. Breakpoints never hit. Console logs are missing. The component acts like the code you just saved does not exist. Your LWC is probably fine, and something environmental is in the way: a stale cache, a configuration detail, or a piece of software sitting between you and the runtime. Here is the order I work through it in.

Understanding Lightning Debug Mode

Debug Mode makes Salesforce generate more detailed JavaScript and HTML for your Lightning components. You get better stack traces, more descriptive error messages, fuller console output. It swaps the optimized component runtime for a verbose one that is friendlier to read while you are debugging.

That output still depends on your browser's developer tools, Chrome DevTools or Firefox Developer Tools, reading and processing it correctly. Anything in that path can break it, from a simple cache problem up to messier interactions with other Salesforce features or with browser extensions.

Common culprits and solutions

Most failures trace back to one of these.

1. Browser cache and cookies

By far the most frequent offender. Salesforce caches heavily for performance, so after you change a component's JavaScript or HTML, the browser may still serve the old version with Debug Mode switched on the whole time. That old file has none of your new logging in it.

Start with a hard refresh: Ctrl + Shift + R in Chrome or Firefox on Windows and Linux, Cmd + Shift + R on Mac.

If that changes nothing, clear cache and cookies for the Salesforce domain properly. Open developer tools (F12), go to the "Application" tab, called "Storage" in Firefox, and under "Clear storage" select "Cache" and "Cookies". You can scope it to .salesforce.com rather than clearing everything. Close the dev tools, refresh Salesforce, try again.

The quick diagnostic is an incognito or private window. It starts clean and skips most existing caches and cookies, so if debugging works there, your normal session is holding a stale copy of something.

2. Incorrect Lightning Debug Mode configuration

It looks like a checkbox and has edges anyway. The setting has to be on for your specific user profile, and you have to be logged in as that user.

From Setup, search the Quick Find box for "Local Development" or "Debug Mode". Check that "Enable access to all data" is on for your profile and, the part people skip, that "Enable Lightning Debug Mode" is on too. The setting applies to the user and to their profile, so testing as a user whose profile does not have Debug Mode enabled gets you nowhere.

Complex session security policies can occasionally interfere as well. That is rare for LWC debugging specifically, but security settings do reach runtime behavior.

After changing user settings, log out of Salesforce completely and log back in. A fresh session is what picks up the new Debug Mode setting.

3. Browser extensions and ad blockers

Extensions, ad blockers and privacy tools above all, can interfere with JavaScript execution and debugging. They block scripts or modify the DOM in ways that quietly break the session.

The systematic approach is dull and it works: disable all your extensions, then re-enable them one by one, testing your LWC after each. Chrome lists them at chrome://extensions/, Firefox at about:addons. Faster still, create a clean browser profile with no extensions installed and debug there. If it works in the clean profile, something in your primary profile is the cause.

4. JavaScript errors in your LWC

If the component throws before execution reaches your debugging statements, the script halts and there is nothing left to step through. Errors in the initialization or rendering lifecycle do this constantly.

1. Open the browser console (F12) and read the "Console" tab properly, including red errors that look unrelated at first glance. LWC error messages are verbose enough to point at the exact line that broke.

   // Example of a common initialization error
   export default class MyComponent extends LightningElement {
       @api recordId;
       data;
   
       connectedCallback() {
           // If 'this.recordId' is undefined or null here, and you try to use it
           // to fetch data, it might throw an error before your console.log
           fetchData(this.recordId).then(result => {
               this.data = result;
               console.log('Data fetched:', this.data);
           });
       }
   }
   
   // Assuming fetchData is defined elsewhere and can throw errors
   function fetchData(recordId) {
       if (!recordId) {
           throw new Error('Record ID is missing!');
       }
       // ... actual data fetching logic ...
       return Promise.resolve({ some: 'data' });
   }
   

2. Wrap the risky parts, data fetching and initialization especially, in try...catch blocks so errors get handled and logged instead of vanishing.

   export default class MyComponent extends LightningElement {
       @api recordId;
       data;
   
       connectedCallback() {
           try {
               // Attempt to fetch data using recordId
               fetchData(this.recordId).then(result => {
                   this.data = result;
                   console.log('Data fetched:', this.data);
               }).catch(error => {
                   console.error('Error fetching data:', error);
               });
           } catch (error) {
               console.error('An unexpected error occurred in connectedCallback:', error);
           }
       }
   }
   

3. Log early and often. Put console.log() through the lifecycle methods (connectedCallback, render, renderedCallback) and through your event handlers so you can see which parts of the component actually ran.

   export default class MyComponent extends LightningElement {
       connectedCallback() {
           console.log('MyComponent: connectedCallback entered.');
           // ... your logic ...
           console.log('MyComponent: connectedCallback exited.');
       }
   
       handleClick() {
           console.log('MyComponent: handleClick initiated.');
           // ... event handling logic ...
           console.log('MyComponent: handleClick completed.');
       }
   }
   

5. Developer Console issues

Sometimes Debug Mode is working and the Salesforce Developer Console is what is interfering with your browser's debugger. It is a capable tool with quirks of its own.

Closing and reopening it resets its internal state, which is worth trying first. After that, remember what it is for: the Developer Console is built around Apex and Aura, while your primary debugging tool for LWCs is the browser's own dev tools. Set breakpoints in the browser's Sources tab. While you are in there, confirm JavaScript debugging is enabled and that you have not accidentally blackboxed any of your component's script files.

6. Firewall or network restrictions

In rare cases an aggressive corporate firewall or network configuration interferes with the JavaScript debugging protocols browsers use. It is uncommon for LWC work specifically, though it does affect other web debugging.

If you can, try the same component from a different network, home Wi-Fi against the office connection, which isolates network problems quickly. If a firewall looks like the cause, that one belongs to your IT department.

Debugging best practices for LWCs

Habits that save the time before anything goes wrong.

• Keep components small and modular. A failure then has fewer places to hide.
• Use console.log deliberately rather than everywhere, and prefix logs with the component name so you can tell at a glance where they came from (e.g., console.log('MyAccountForm:', this.formData);).
• The debugger; statement pauses execution on that exact line when developer tools are open and debugging is enabled, which beats guessing where to click.

  export default class MyComponent extends LightningElement {
      @api value;
  
      renderedCallback() {
          console.log('Component rendered');
          // Pause execution here if DevTools are open
          debugger;
          console.log('After debugger statement');
      }
  }
  

• Learn the lifecycle hooks (connectedCallback, renderedCallback, disconnectedCallback, errorCallback) well enough to know which is executing when. Knowing where you are in the lifecycle is what makes everything else fast.
• The Lightning Inspector browser extension shows component structure, properties and events, which helps when you are trying to work out component state. Browser dev tools are still the main instrument for LWCs.

Key takeaways

When an LWC will not cooperate with Lightning Debug Mode, work the list instead of guessing. Browser cache, user configuration, and interference from extensions account for most of it.

• Start with a hard refresh, then clear browser cache and cookies.
• Check the "Enable Lightning Debug Mode" setting on your user in Setup.
• Disable browser extensions, then re-enable them one by one to find the offender.
• Read the browser console carefully for JavaScript errors.
• Use debugger; statements and prefixed console.log for precise control.
• Browser dev tools are your primary LWC debugging interface.