What Can Template Literals Do?

A template literal is a string written between backticks instead of quotes. That single change buys you three things: you can drop values into the middle of the text, you can write across several lines without escaping, and you can hand the whole thing to a function as a tagged template.

const name = "Ada";
const score = 96.5;

const greeting = `Hello ${name}, you scored ${score} points`;
console.log(greeting);

// Expressions and method calls work inside the substitution.
console.log(`Upper: ${name.toUpperCase()}`);
console.log(`Rounded: ${(score / 100).toFixed(2)}%`);

The substitution syntax evaluates the expression between the dollar sign and the brace and converts the result to a string. Anything legal in an expression is legal there, including ternaries, arithmetic and function calls. The result is always a string, so an object becomes its usual text form.

The second feature is multiline strings. A template literal can contain literal line breaks, and the newlines are part of the string. That removes a pile of concatenation with newline characters, which used to be the main reason people reached for array joins.

The third is escaping. A backslash inside a template literal still works, but the backtick itself can be included with a backslash, and the dollar-brace sequence can be escaped with a backslash as well, which is how you write a literal dollar-brace in text.

The trade-off worth mentioning is that template literals are not a general-purpose formatter. If you build a long string with many substitutions, the concatenation is faster and the result is easier to read in a diff.

For anything longer than a line or two, template literals are usually the better choice, and the difference is not only about line length. The reason is that concatenation with the plus sign has to be split across many string literals and joined with the operator, which means the expression is hard to read, easy to break in the middle of a word, and produces a lot of intermediate strings.

A template literal keeps the shape of the text intact. The whitespace, the indentation and the line breaks are exactly as you typed them, which means you can lay out a block of markup or SQL in the source and see it as it will appear at runtime. With concatenation, the layout of the code is dominated by quotes and plus signs, and the text is buried.

There is a subtle but important consequence. Whitespace inside a template literal is significant, so an indented multi-line template will include the indentation in the output. That matters when you are generating markup, and it is the reason some teams use a helper that strips the common indentation, or a tagged template that de-indents automatically.

Performance is a reasonable follow-up. Modern engines optimise both forms well, and for typical string sizes the difference is negligible. But template literals can still allocate an intermediate string for every substitution, so for very hot paths that build large strings in a loop, an array of parts joined once at the end is often the better pattern.

You put a function in front of the template literal. The function receives the literal text chunks as its first argument and the evaluated substitutions as the rest. It returns whatever you want, usually a string.

function highlight(strings, ...values) {
  console.log("chunks:", strings.length);   // 3
  console.log("raw:", strings.raw.join("|"));

  return strings.reduce((out, chunk, index) => {
    const value = values[index] === undefined ? "" : values[index];
    return out + chunk + value;
  }, "");
}

const name = "Ada";
const year = 2026;

const output = highlight`Hello ${name}, welcome to ${year}`;
console.log(output);

The strings argument is an array of the literal pieces between the substitutions, so for a template with two substitutions you get three chunks. The values argument holds the evaluated substitutions in order. The reduce in the example rebuilds the original text, which is what a tag that only wanted to inspect the parts would do.

The raw property is the reason tags are worth building. It gives you the literal source of each chunk with the escape sequences left unprocessed, so you can see exactly what the author typed. That is what lets a tag support custom escapes, sanitise interpolated values, or format a template for another language, which is exactly how the standard SQL tag and the CSS-in-JS libraries work.

Two notes. A tag does not have to return a string; it can return any value, and some libraries return an object describing the parsed template. And because the tag receives the raw text, it is a natural place to enforce rules, such as rejecting an interpolated value that is not properly escaped.