Keep your client-side code readable and debuggable even after you've combined, minified or compiledit. Usesource maps to map your source code to your compiled code in theSources panel.

Get started with preprocessors

Source maps from preprocessors cause DevTools to load your original files in addition to your minified ones.

Chrome will actually run your minified code but theSources panel will show you the code you author.You can set breakpoints and step through code in source files and all the errors, logs, and breakpoints will automatically map.

This gives you the appearance of debugging the code as you wrote it, as opposed to code that is served by your development server and executed by the browser.

To use source maps in theSources panel:

• Use only the preprocessors that can produce source maps.
• Verify that your web server can serve source maps.

Use a supported preprocessor

Common preprocessors used in combination with source maps include but aren't limited to:

• Transpilers:Babel
• Compilers:TypeScript andDart
• Minifiers:terser
• Bundlers and development servers:Webpack,Vite,esbuild, andParcel

For an extended list, seeSource maps: Languages, tools, and other info.

Enable source maps in Settings

InSettings >Preferences >Sources, make sure to checkJavaScript source maps.

Note: You might also want to checkCSS source maps.

Check if source maps loaded successfully

SeeDeveloper Resources: View and load source maps manually.

Debugging with source maps

Note: This tutorial usesthis demo as an example.

With source mapsready andenabled, you can do the following:

1. Open your website's sources in theSources panel.

2. To focus only on the code you author,group authored and deployed files in the file tree. Then expand theAuthored section and open your original source file in theEditor.

   

3. Set a breakpoint as you normally would. For example, alogpoint. Then run the code.

   

4. Notice that theEditor puts a link to the deployed file in the status bar at the bottom. Similarly, it does so for deployed CSS files.

   

5. Open theConsole drawer. In this example, next to the logpoint's message, the Console shows a link to the original file, not the deployed one.

   

6. Change thebreakpoint type to aregular one and run the code again. The execution pauses this time.

   

   Notice that theCall Stack pane shows the name of the original file and not the deployed one.

7. In the status bar at the bottom of theEditor, click the link to the deployed file. TheSources panel takes you to the corresponding file.

When you open any deployed file, DevTools notifies you if it found the//# sourceMappingURL comment and the associated original file.

Notice that theEditor automatically pretty-printed the deployed file. In reality, it contains all the code in a single line, except for the//# sourceMappingURL comment.

Nameeval() calls with#sourceURL

The#sourceURL lets you simplify debuggingwhen dealing witheval() calls. This helper looks very similar to the//# sourceMappingURL property. For more information, see theSource Map V3 specification.

The//# sourceURL=/path/to/source.file comment tells the browser to look for the source file when you useeval(). This helps you name your evaluations and inline scripts and styles.

Test it on thisdemo page:

1. Open the DevTools and go to theSources panel.
2. On the page, enter an arbitrary filename into theName your code: input field.
3. Click theCompile button. An alert appears with the evaluated sum from the CoffeeScript source.
4. In the file tree on thePage pane, open a new file with the custom filename you entered. It contains the compiled JavaScript code that has the// #sourceURL comment with the original name of the source file.
5. To open the source file, click the link in the status bar of theEditor.