This Ecma Standard defines the Source Map Format, used for mapping transpiled source code back to the original sources.
+
The source map format has the following goals:
+
+
Support source-level debugging allowing bidirectional mapping
+
Support server-side stack trace deobfuscation
+
+
+ The document at https://tc39.es/source-map/ is the most accurate and up-to-date source map specification. It contains the content of the most recently published snapshot plus any modifications that will be included in the next snapshot.
+
+ The original source map format (v1) was created by Joseph Schorr for use by Closure Inspector to enable source-level debugging of optimized JavaScript code (although the format itself is language agnostic). However, as the size of the projects using source maps expanded, the verbosity of the format started to become a problem. The v2 format
+ [V2Format] was created by trading some simplicity and flexibility to reduce the overall size of the source map. Even with the changes made with the v2 version of the format, the source map file size was limiting its usefulness. The v3 format is based on suggestions made by Pavel Podivilov (Google).
+
+
The source map format does not have version numbers anymore, and it is instead hard-coded to always be "3".
+
+
+
+
ALTERNATIVE COPYRIGHT NOTICE AND COPYRIGHT LICENSE
By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.
+
Permission under Ecma's copyright to copy, modify, prepare derivative works of, and distribute this work, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the work or portions thereof, including modifications:
+
+
The full text of this ALTERNATIVE COPYRIGHT NOTICE AND COPYRIGHT LICENSE in a location viewable to users of the redistributed or derivative work.
+
Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the Ecma alternative copyright notice should be included.
THIS WORK IS PROVIDED “AS IS,” AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE DOCUMENT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT.
+
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders.
+
+
+
Source Map Format Specification
+
+
+
1 Scope
+
+
This Standard defines the source map format, used by different types of developer tools to improve the debugging experience of code compiled to JavaScript, WebAssembly, and CSS.
+
+
+
+
2 Conformance
+
+
A conforming source map document is a JSON document that conforms to the structure detailed in this specification.
+
A conforming source map generator should generate documents which are conforming source map documents, and can be decoded by the algorithms in this specification without reporting any errors (even those which are specified as optional).
+
A conforming source map consumer should implement the algorithms specified in this specification for retrieving (where applicable) and decoding source map documents. A conforming consumer is permitted to ignore errors or report them without terminating where the specification indicates that an algorithm may optionally report an error.
A [base64] value, where the most significant bit (the 6th bit) is used as the continuation bit, and the "digits" are encoded into the string least significant first, and where the least significant bit of the first digit is used as the sign bit.
+
+
+
The values that can be represented by the VLQ Base64 encoded are limited to 32-bit quantities until some use case for larger values is presented. This means that values exceeding 32-bits are invalid and implementations may reject them. The sign bit is counted towards the limit, but the continuation bits are not.
+
+
+
+
+ The string "iB" represents a Base64 VLQ with two digits. The first digit "i" encodes the bit pattern 0x100010, which has a continuation bit of 1 (the VLQ continues), a sign bit of 0 (non-negative), and the value bits 0x0001.
+ The second digit B encodes the bit pattern 0x000001, which has a continuation bit of 0, no sign bit, and value bits 0x00001. The decoding of this VLQ string is the number 17.
+
+
+
+
+ The string "V" represents a Base64 VLQ with one digit. The digit "V" encodes the bit pattern 0x010101, which has a continuation bit of 0 (no continuation), a sign bit of 1 (negative), and the value bits 0x1010. The decoding of this VLQ string is the number -10.
+
+
+
+
+
4.4 Source Mapping URL
+
+
The URL referencing the location of a source map from the Generated code.
+
+
+
4.5 Column
+
+
The zero-based indexed offset within a line of the generated code. How this offset is measured can depend on the content type. For JavaScript and CSS based source maps, they are defined to be in UTF-16 code units analogous to JavaScript string indices. That means that "A" (LATIN CAPITAL LETTER A) measures as 1 code unit, and "🔥" (FIRE) measures as 2 code units. For WebAssembly, columns are defined as byte offsets from the beginning of the binary content (and there is only one group representing a line). Source maps for other content types may diverge from this.
+
+
+
+
+
+
5 Source Map Format
+
+
+
+
A source map is a JSON document containing a top-level JSON object with the following structure:
+ version is the version field which must always be the number
+ 3 as an integer. The source map may be rejected if the field has any other value.
+
+
+ file is an optional name of the generated code that this source map is associated with. It's not specified if this can be a URL, relative path name, or just a base name. Source map generators may choose the appropriate interpretation for their contexts of use.
+
+
+ sourceRoot is an optional source root string, used for relocating source files on a server or removing repeated values in the
+ sources entry. This value is prepended to the individual entries in the
+ sources field.
+
+
+ sources is a list of original sources used by the mappings entry. Each entry is either a string that is a (potentially relative) URL or null if the source name is not known.
+
+
+ sourcesContent is an optional list of source content (i.e., the Original Source) strings, used when the source cannot be hosted. The contents are listed in the same order as the sources. Entries may be null if some original sources should be retrieved by name.
+
+
names is an optional list of symbol names which may be used by the mappings entry.
+ ignoreList is an optional list of indices of files that should be considered third party code, such as framework code or bundler-generated code. This allows developer tools to avoid code that developers likely don't want to see or step through, without requiring developers to configure this beforehand. It refers to the sources array and lists the indices of all the known third-party sources in the source map. Some browsers may also use the deprecated x_google_ignoreList field if ignoreList is not present.
+
+
+
+
A decoded source map is a struct with the following fields:
each group representing a line in the generated file is separated by a semicolon (;)
+
each segment is separated by a comma (,)
+
each segment is made up of 1, 4, or 5 variable length fields.
+
+
+
+
The fields in each segment are:
+
+
+
+
The zero-based starting column of the line in the generated code that the segment represents. If this is the first field of the first segment, or the first segment following a new generated line (;), then this field holds the whole Base64 VLQ. Otherwise, this field contains a Base64 VLQ that is relative to the previous occurrence of this field. Note that this is different from the subsequent fields below because the previous value is reset after every generated line.
+
If present, the zero-based index into the sources list. This field contains a Base64 VLQ relative to the previous occurrence of this field, unless it is the first occurrence of this field, in which case the whole value is represented.
+
If present, the zero-based starting line in the original source. This field contains a Base64 VLQ relative to the previous occurrence of this field, unless it is the first occurrence of this field, in which case the whole value is represented. Must be present if there is a source field.
+
If present, the zero-based starting column of the line in the original source. This field contains a Base64 VLQ relative to the previous occurrence of this field, unless it is the first occurrence of this field, in which case the whole value is represented. Must be present if there is a source field.
+
If present, the zero-based index into the names list associated with this segment. This field contains a Base64 VLQ relative to the previous occurrence of this field, unless it is the first occurrence of this field, in which case the whole value is represented.
+
+
+
+
+
+
The purpose of this encoding is to reduce the source map size. VLQ encoding reduced source maps by 50% relative to the [V2Format] in tests performed using Google Calendar.
+
+
+
+
+
+
Segments with one field are intended to represent generated code that is unmapped because there is no corresponding original source code, such as code that is generated by a compiler. Segments with four fields represent mapped code where a corresponding name does not exist. Segments with five fields represent mapped code that also has a mapped name.
+
+
+
+
+
+
Using file offsets was considered but rejected in favor of using line/column data to avoid becoming misaligned with the original due to platform-specific line endings.
+
+
+
+
A decoded mapping is a struct with the following fields:
Increase originalColumn by relativeOriginalColumn.
+
If any of sourceIndex, originalLine, or originalColumn are less than 0, or if sourceIndex is greater than or equal to sources's size, optionally report an error.
+
+ Else,
+
+
Set decodedMapping's originalSource to sources[sourceIndex].
+
Set decodedMapping's originalLine to originalLine.
Generated code positions that may have mapping entries are defined in terms of input elements as per ECMAScript Lexical Grammar. Mapping entries must point to either:
+ If the sources are not absolute URLs after prepending the sourceRoot, the sources are resolved relative to the SourceMap (like resolving the script src attribute in an HTML document).
+
To decode source map sources given a URL baseURL,
+ a string or null sourceRoot,
+ a list of either strings or nulls sources,
+ a list of either strings or nulls sourcesContent,
+ and a list of numbers ignoredSources,
+ run the following steps:
+
+
+
+
Let decodedSources be a new empty list.
+
Let sourceURLPrefix be "".
+
+ If sourceRoot is not null, then:
+
+
+ If sourceRoot contains the code point U+002F (/), then:
+
+
Let index be the index of the last occurrence of U+002F (/) in sourceRoot.
+
Set sourceURLPrefix to the substring of sourceRoot from 0 to index + 1.
+
+
+
Else, set sourceURLPrefix to the concatenation of sourceRoot and "/".
+
+
+
+ For each source of sources with index index:
+
+
If index is in ignoredSources, set decodedSource's ignored to true.
+
If sourcesContent's size is greater than or equal to index, set decodedSource's content to sourcesContent[index].
+
Append decodedSource to decodedSources.
+
+
+
Return decodedSources.
+
+
+
+
+
+
Implementations that support showing source contents but do not support showing multiple sources with the same URL and different content will arbitrarily choose one of the various contents corresponding to the given URL.
+
+
+
+
+
+
+
5.3 Extensions
+
Source map consumers must ignore any additional unrecognized properties, rather than causing the source map to be rejected, so that additional features can be added to this format without breaking existing users.
+
+
+
+
+
6 Index Map
+
+
To support concatenating generated code and other common post-processing, an alternate representation of a map is supported:
The index map follows the form of the standard map. Like the regular source map, the file format is JSON with a top-level object. It shares the version and file field from the regular source map, but gains a new sections field.
offset is an object with two fields, line and column, that represent the offset into generated code that the referenced source map represents.
+
map is an embedded complete source map object. An embedded map does not inherit any values from the containing index map.
+
+
+
+
The sections must be sorted by starting position and the represented sections must not overlap.
+
+
+
+
+
+
7 Retrieving Source Maps
+
+
+
7.1 Linking generated code to source maps
+
+
While the source map format is intended to be language and platform agnostic, it is useful to define how to reference to them for the expected use-case of web server-hosted JavaScript.
+
There are two possible ways to link source maps to the output. The first requires server support in order to add an HTTP header and the second requires an annotation in the source.
+
Source maps are linked through URLs as defined in [URL]; in particular, characters outside the set permitted to appear in URIs must be percent-encoded and it may be a data URI. Using a data URI along with sourcesContent allows for a completely self-contained source map.
+
The HTTP sourcemap header has precedence over a source annotation, and if both are present, the header URL should be used to resolve the source map file.
+
Regardless of the method used to retrieve the Source Mapping URL the same process is used to resolve it, which is as follows:
+
When the Source Mapping URL is not absolute, then it is relative to the generated code's source origin. The source origin is determined by one of the following cases:
+
+
+
+
+ If the generated source is not associated with a script element that has a src attribute and there exists a //# sourceURL comment in the generated code, that comment should be used to determine the source origin.
+
+
+
Previously, this was //@ sourceURL, as with
+ //@ sourceMappingURL, it is reasonable to accept both but
+ //# is preferred.
+
+
+
+
+
If the generated code is associated with a script element and the script element has a src attribute, the src attribute of the script element will be the source origin.
+
If the generated code is associated with a script element and the script element does not have a src attribute, then the source origin will be the page's origin.
+
If the generated code is being evaluated as a string with the eval() function or via new Function(), then the source origin will be the page's origin.
+
+
+
+
+
7.1.1 Linking through HTTP headers
+
+
If a file is served through HTTP(S) with a sourcemap header, the value of the header is the URL of the linked source map.
+
sourcemap:<url>
+
+
+
+
Previous revisions of this document recommended a header name of x-sourcemap. This is now deprecated;
+ sourcemap is now expected.
+
+
+
+
+
+
+
7.1.2 Linking through inline annotations
+
+
The generated code should include a comment, or the equivalent construct depending on its language or format, named sourceMappingURL and that contains the URL of the source map. This specification defines how the comment should look like for JavaScript, CSS, and WebAssembly. Other languages should follow a similar convention.
+
For a given language there can be multiple ways of detecting the sourceMappingURL comment, to allow for different implementations to choose what is less complex for them. The generated code unambiguously links to a source map if the result of all the extraction methods is the same.
Having multiple ways to extract a source map URL, that can lead to different results, can have negative security and privacy implications. Implementations that need to detect which source maps are potentially going to be loaded are strongly encouraged to always apply both algorithms, rather than just assuming that they will give the same result.
+
A fix to this problem is being worked on, and is expected to be included in a future version of the standard. It will likely involve early returning from the below algorithms whenever there is a comment (or comment-like) that contains the characters U+0060 (`), U+0022 ("), or U+0027 ('), or the sequence U+002A U+002F (*/).
+
+
+
+
+
7.1.2.1 Extraction methods for JavaScript sources
+
+
To extract a Source Map URL from JavaScript through parsing a string source, run the following steps:
+
+
+
+
Let tokens be the list of tokens obtained by parsing source according to [ECMA-262].
We reset
+ lastURL to null whenever we find a non-comment code character.
+
+
+
+
+
Return lastURL.
+
+
+
+
+
+
The algorithm above has been designed so that the source lines can be iterated in reverse order, returning early after scanning through a line that contains a sourceMappingURL comment.
+
+
+
+
+
+
The algorithm above is equivalent to the following JavaScript implementation:
+
const JS_NEWLINE =/^/m;
+
+// This RegExp will always match one of the following:
+// - single-line comments
+// - "single-line" multi-line comments
+// - unclosed multi-line comments
+// - just trailing whitespaces
+// - a code character
+// The loop below differentiates between all these cases.
+const JS_COMMENT =
+/\s*(?:\/\/(?<single>.*)|\/\*(?<multi>.*?)\*\/|\/\*.*|$|(?<code>[^\/]+))/uym;
+
+const PATTERN =/^[@#]\s*sourceMappingURL=(\S*?)\s*$/;
+
+let lastURL =null;
+for(const line of source.split(JS_NEWLINE)){
+ JS_COMMENT.lastIndex =0;
+ while(JS_COMMENT.lastIndex < line.length){
+ let commentMatch = JS_COMMENT.exec(line).groups;
+ let comment = commentMatch.single ?? commentMatch.multi;
+ if(comment !=null){
+ let match = PATTERN.exec(comment);
+ if(match !==null) lastURL = match[1];
+ }elseif(commentMatch.code !=null){
+ lastURL =null;
+ }else{
+ // We found either trailing whitespaces or an unclosed comment.
+ // Assert: JS_COMMENT.lastIndex === line.length
+ }
+ }
+}
+return lastURL;
+
+
+
+
+
To match a Source Map URL in a comment comment (a string), run the following steps:
+
+
+
+
Let pattern be the regular expression /^[@#]\s*sourceMappingURL=(\S*?)\s*$/.
Let name be the name of customSection, decoded as UTF-8.
+
+ If name is "sourceMappingURL", then:
+
+
Let value be the bytes of customSection, decoded as UTF-8.
+
If value is failure, return null.
+
Return value.
+
+
+
+
+
Return null.
+
+
+
+
+ Since WebAssembly is not a textual format and it does not support comments, it supports a single unambiguous extraction method. The URL is encoded using
+ [WasmNamesBinaryFormat], and it's placed as the content of the
+ custom section. It is invalid for tools that generate WebAssembly code to generate two or more
+ custom sections with the "sourceMappingURL" name.
+
+
+
+
+
+
+
7.2 Fetching Source Maps
+
+
To fetch a source map given a URL url, run the following steps:
+
+
+
+
Let promise be a new promise.
+
Let request be a new request whose URL is url.
+
+ Fetch request with processResponseConsumeBody set to the following steps given response response and null, failure, or a byte sequence bodyBytes:
+
+
If bodyBytes is null or failure, reject promise with a TypeError and abort these steps.
+
+ If url's scheme is an HTTP(S) scheme and bodyBytes starts with `)]}'`, then:
+
+
+ While bodyBytes's length is not 0 and bodyBytes's 0th byte is not an HTTP newline byte:
+
remove the 0th byte from bodyBytes.
+
+
+
For historic reasons, when delivering source maps over HTTP(S), servers may prepend a line starting with the string )]}' to the source map.
+
)]}'garbage here
+{"version":3,...}
+ is interpreted as
+
{"version":3,...}
+
+
+
+
+
+
Let sourceMap be the result of parsing JSON bytes to a JavaScript value given
+ bodyBytes.
+
+
If the previous step threw an error, reject promise with that error.
+
Otherwise, resolve promise with sourceMap.
+
+
+
Return promise.
+
+
+
+
+
+
+
8 Conventions
+
+
The following conventions should be followed when working with source maps or when generating them.
+
+
+
8.1 Source Map Naming
+
+
Commonly, a source map will have the same name as the generated file but with a .map extension. For example, for page.js a source map named page.js.map would be generated.
+
+
+
+
8.2 Linking eval'd code to named generated code
+
+
There is an existing convention that should be supported for the use of source maps with eval'd code, it has the following form:
Stack tracing mapping without knowledge of the source language is not covered by this document.
+
+
+
+
10 Multi-level Mapping Notes
+
+
It is getting more common to have tools generate sources from some DSL (templates) or compile TypeScript -> JavaScript -> minified JavaScript, resulting in multiple translations before the final source map is created. This problem can be handled in one of two ways. The easy but lossy way is to ignore the intermediate steps in the process for the purposes of debugging, the source location information from the translation is either ignored (the intermediate translation is considered the ”Original Source“) or the source location information is carried through (the intermediate translation hidden). The more complete way is to support multiple levels of mapping: if the Original Source also has a source map reference, the user is given the choice of using that as well.
+
However, It is unclear what a "source map reference" looks like in anything other than JavaScript. More specifically, what a source map reference looks like in a language that doesn't support JavaScript-style single-line comments.
Having multiple ways to extract a source map URL, that can lead to different results, can have negative security and privacy implications. Implementations that need to detect which source maps are potentially going to be loaded are strongly encouraged to always apply both algorithms, rather than just assuming that they will give the same result.
+
A fix to this problem is being worked on, and is expected to be included in a future version of the standard. It will likely involve early returning from the below algorithms whenever there is a comment (or comment-like) that contains the characters U+0060 (`), U+0022 ("), or U+0027 ('), or the sequence U+002A U+002F (*/).
Ecma International Rue du Rhone 114 CH-1204 Geneva Tel: +41 22 849 6000 Fax: +41 22 849 6001 Web: https://www.ecma-international.org Ecma is the registered trademark of Ecma International.