Import and Export in React Explained — No Fluff, Just What You Need

when I first started writing React, I just copied the import lines at the top of every file without really thinking about them. They worked. I moved on.

Then one day I tried to do something slightly different and got a weird error, and I realized I had no idea what I was actually doing.

Took me longer than I’d like to admit to properly sit down and figure this out. Hopefully this saves you that time.

The Whole Point of Import and Export

React projects are split across multiple files. Your Header is in one file, your Button is in another, your utility functions are somewhere else entirely. Import and export is what lets all of those files talk to each other.

You export something when you want other files to be able to use it. You import it when you need to actually use it somewhere.

That’s the whole concept. Everything else is just syntax.

Default Export — The One You’ll Use Most

When a file has one main thing in it — almost always a component — you export it as the default.

jsx

// Header.jsx
function Header() {
  return <h1>Welcome to TechCanva</h1>;
}

export default Header;

Then wherever you need it:

jsx

// App.jsx
import Header from './Header';

function App() {
  return (
    <div>
      <Header />
    </div>
  );
}

The part that confused me at first — when you import a default export, you can call it literally anything. This works:

js

import MyHeader from './Header';
import SomeRandomName from './Header';
import BlahBlah from './Header';

All of these grab the same thing. JavaScript just takes whatever was exported as the default from that file and gives it whatever name you used. Most people stick to the same name as the component just to avoid confusion, but the option is there.

Named Export — When a File Has Multiple Things to Share

Default exports are one-per-file. Named exports are for when you’ve got several things coming out of the same file — like a utilities file.

js

// utils.js
export const companyName = "TechCanva";

export function getYear() {
  return new Date().getFullYear();
}

Importing them:

jsx

import { companyName, getYear } from './utils';

See the curly braces? Those are not optional with named exports. And unlike default exports, the name has to match exactly — case and all. If you exported companyName and you type CompanyName in your import, it won’t find it. JavaScript isn’t going to guess what you meant.

This is probably the single thing that trips beginners up the most — mixing up when to use curly braces and when not to.

Quick mental shortcut that helped me:

• Default export → no curly braces
• Named export → curly braces, exact name

When You’ve Got Both in the Same File

Totally valid to have one default export and some named exports in the same file. Happens all the time.

jsx

// User.jsx
export const role = "Developer";

function User() {
  return <h1>User Component</h1>;
}

export default User;

To import both:

jsx

import User, { role } from './User';

User is the default, so no curly braces. role is named, so curly braces. Both in one line. Once you’ve written this a few times it becomes muscle memory.

Couple More Things That Come Up

Renaming a named export on import — useful when you’ve already got a variable with the same name, or you just want something shorter in that particular file:

js

import { companyName as company } from './utils';

Now you use company inside that file. The original export is still called companyName everywhere else — you’re just giving it a local alias.

Grabbing everything at once — if a file has a bunch of named exports and you want all of them:

js

import * as data from './utils';

console.log(data.companyName);
console.log(data.getYear());

I don’t use this pattern often but it exists and occasionally it’s the cleanest option.

The imports you’ll write constantly in React:

js

import { useState, useEffect } from 'react';   // hooks
import './App.css';                             // styles
import logo from './logo.png';                 // images
import Header from './components/Header';      // your own components

Worth noting — useState and useEffect are named exports from the React package. That’s why they need curly braces. A lot of people memorize this without realizing why, then get confused when they see other imports without curly braces.

The Mistakes I Made (And See Others Make)

Forgetting curly braces on a named import:

js

// wrong
import useState from 'react';

// right
import { useState } from 'react';

This one gives you an error that doesn’t immediately make it obvious what went wrong, especially early on.

Putting curly braces around a default export:

js

// wrong
import { Header } from './Header';

// right
import Header from './Header';

If you exported something as the default and you import it with curly braces, React doesn’t find it. You’ll get undefined or an error and spend twenty minutes confused.

Getting the file path wrong:

js

// wrong — JavaScript looks in node_modules, not your files
import Header from 'Header';

// right
import Header from './Header';

The ./ means “look in the current folder.” Without it JavaScript assumes you’re importing a package. Your component is obviously not a package, so nothing works. I made this mistake embarrassingly often in the first couple weeks.

How Most React Projects Handle This in Practice

There’s no official rule, but the pattern almost everyone settles into:

Components get default exports. Utility functions, constants, helper stuff — named exports. One component per file.

src/
├── components/
│   ├── Header.jsx     →  export default Header
│   ├── Footer.jsx     →  export default Footer
│   └── Button.jsx     →  export default Button
│
├── utils/
│   └── helper.js      →  export const formatDate, export const getUser
│
└── App.jsx

Imports stay readable:

js

import Header from './components/Header';
import { formatDate } from './utils/helper';

Not a hard rule, just the convention most teams land on. Stick to it and your code stays predictable.

Last Thing

This genuinely is one of those topics that clicks after you’ve written it enough times. The first week it feels like you’re constantly second-guessing whether to use curly braces. Two weeks later you’re not even thinking about it.

If you get an import error, the first three things to check are: did I forget curly braces, did I accidentally add curly braces, or is my file path wrong. Covers probably 90% of the issues you’ll run into.

Got a question about a specific import error you’re seeing? Drop it in the comments.