Introduction

In JavaScript modules, export default marks one main value from a file as its default export. It is useful when a module is centered around one primary thing, such as one function, one class, or one configuration object, and you want importing code to reference it without using curly braces.

Core Sections

What export default means

A module can have many named exports, but only one default export. The default export is the module’s “main” exported value.

1function add(a, b) {
2  return a + b;
3}
4
5export default add;

Another file can import it like this:

import add from "./mathUtils.js";

console.log(add(2, 3));

Notice that the import uses no curly braces. That is the most obvious syntactic difference between a default export and a named export.

How default export differs from named export

Named exports require the same exported name to be imported with braces.

1export function add(a, b) {
2  return a + b;
3}
4
5export function subtract(a, b) {
6  return a - b;
7}

import { add, subtract } from "./mathUtils.js";

A default export behaves differently:

export default function add(a, b) {
  return a + b;
}

import anyNameYouWant from "./mathUtils.js";

The importing file can choose the local name freely. That flexibility is one reason default exports feel convenient, but it can also make large codebases less consistent if different files import the same module under different names.

When default exports are a good fit

Default exports are usually a good fit when the file exists mainly to provide one central thing.

Examples:

• a React component file that exports one component
• a utility file centered on one main function
• a configuration module that exports one object

1export default class UserService {
2  getName() {
3    return "Ada";
4  }
5}

1import UserService from "./UserService.js";
2
3const service = new UserService();
4console.log(service.getName());

If the file naturally contains several equally important exports, named exports are often clearer.

You can mix default and named exports

JavaScript allows both styles in the same module.

1export const version = "1.0.0";
2
3export default function connect() {
4  return "connected";
5}

1import connect, { version } from "./api.js";
2
3console.log(connect());
4console.log(version);

This works, but it should be used deliberately. Overusing mixed exports can make module interfaces harder to scan.

Re-exporting and dynamic import behavior

When you use dynamic import(), the module object exposes the default export under the .default property.

1async function loadMath() {
2  const module = await import("./mathUtils.js");
3  console.log(module.default(4, 5));
4}
5
6loadMath();

That detail is important when debugging dynamic imports, because the syntax differs from static import add from ... style.

Design tradeoff: convenience versus consistency

The main tradeoff with default exports is that they are concise but less explicit. Named exports force consistency because the exported name appears in both files. Default exports are smoother for single-purpose modules, but in large teams some developers prefer named exports almost everywhere because they are easier to search and refactor consistently.

Neither approach is universally correct. The question is whether the module really has one clear primary export.

Common Pitfalls

• Assuming export default and named exports use the same import syntax leads to missing or incorrect curly braces.
• Using default exports everywhere can make imports inconsistent because each caller can choose a different local name.
• Forgetting that a module can have only one default export causes syntax errors in files that try to declare several of them.
• Mixing default and named exports casually can make the module interface less obvious to readers.
• Forgetting that dynamic imports expose the default export as .default causes confusion during debugging.

Summary

• 'export default marks one main exported value from a JavaScript module.'
• It is imported without curly braces and can be renamed freely by the importer.
• Named exports are better when a module exposes several equally important values.
• Mixing default and named exports is allowed, but it should be done deliberately.
• Choose default export when the module has one clear primary responsibility, not just because the syntax is shorter.