Using Inline CSS in React with JavaScript Objects (A Simple Explanation)

When someone comes to React from plain HTML and CSS, styling usually feels familiar at first. You write a class, add CSS rules, and everything behaves the way you expect. Then React introduces inline styles, and suddenly things feel slightly off. Not wrong, just… different.

I remember the first time I tried to add inline CSS in React. I wrote something that looked completely normal to me, and React threw an error. It wasn’t dramatic, but it was confusing. That confusion usually comes from one core idea: React inline styles are not written as CSS strings. They are written as JavaScript objects.

Once that idea settles in, the rest slowly makes sense.

Let’s walk through this calmly.

Why Inline CSS in React Works Differently

In normal HTML, inline styles look like this:

<div style="background-color: #f0f0f0;"></div>

That works because HTML expects a string.

React doesn’t.

React uses JSX, which is closer to JavaScript than HTML. So when you write styles inline, React expects an object, not a string. That object follows JavaScript rules, not CSS rules.

This is where people usually trip up.

The Correct Way: Using a JavaScript Style Object

A clean and common approach is defining your styles as a JavaScript object.

const styleCard = {
  backgroundColor: "#f0f0f0",
};

And then applying it like this:

<div className="cards" style={styleCard}></div>

At first glance, it looks slightly strange. But it’s actually very logical once you break it down.

  • style={} means you’re passing JavaScript
  • styleCard is a JavaScript object
  • backgroundColor uses camelCase instead of hyphenated CSS

That camelCase part is important. React doesn’t understand background-color. It only understands backgroundColor.

This is not React being difficult. It’s React staying consistent with JavaScript syntax.

Why CamelCase Is Required

CSS properties like background-color, font-size, or border-radius use hyphens. JavaScript object keys don’t work well with hyphens unless you wrap them in quotes, and React avoids that approach.

So React converts CSS properties into camelCase versions:

  • background-colorbackgroundColor
  • font-sizefontSize
  • border-radiusborderRadius

Once you accept this rule, it becomes second nature. You stop thinking about it after a while.

The Incorrect Way (and Why It Fails)

You mentioned this example:

<div className="cards" style={backgroundColor:"#f0f0f0"}></div>

This looks reasonable if you’re thinking in HTML terms, but it won’t work in React.

Why?

Because style={} expects one JavaScript value, not a loose key-value pair. What you’re actually doing here is giving React invalid JavaScript syntax.

React expects:

  • either a variable holding an object
  • or an object written directly inside the curly braces

Which brings us to the correct inline version.

Inline Object Directly Inside JSX (Valid Approach)

You can define the style object directly inside JSX, like this:

<div
  className="rest"
  style={{ backgroundColor: "#f0f0f0" }}
></div>

Notice the double curly braces.

  • First {} → tells JSX you’re writing JavaScript
  • Second {} → defines a JavaScript object

This pattern looks odd at first, but it’s very common in React codebases.

When Defining a Separate Style Object Is Better

While inline objects work fine, defining a separate style object often reads better, especially when styles grow.

Compare these two:

<div
  style={{
    backgroundColor: "#f0f0f0",
    padding: "16px",
    borderRadius: "6px",
  }}
></div>

Versus:

const cardStyle = {
  backgroundColor: "#f0f0f0",
  padding: "16px",
  borderRadius: "6px",
};
<div style={cardStyle}></div>

The second version feels calmer. Easier to scan. Easier to change later. Especially when you come back to the file after a few weeks and don’t fully remember what you wrote.

That alone is a good reason to separate it.

Values Are Strings (Mostly)

Another small detail that often gets missed: most CSS values in React are strings.

backgroundColor: "#f0f0f0"
padding: "10px"
width: "100%"

There are exceptions. Some numeric values don’t need units, like zIndex or opacity.

opacity: 0.9
zIndex: 10

But when in doubt, use strings. It keeps things predictable.

Inline Styles vs CSS Classes (A Realistic View)

Inline styles are not better or worse than CSS classes. They just solve different problems.

Inline styles are useful when:

  • Styles depend on props or state
  • Values change dynamically
  • You want quick, component-level styling

CSS classes are better when:

  • Styles are reused
  • Layout is complex
  • Media queries are needed
  • Hover and focus states matter

React doesn’t force you to choose one forever. Most real projects use both. That balance feels natural once you stop overthinking it.

A Simple, Clean Example Putting It All Together

const styleCard = {
  backgroundColor: "#f0f0f0",
  padding: "20px",
  borderRadius: "8px",
};
<div className="cards" style={styleCard}>
  Simple content goes here
</div>

Nothing fancy. Nothing clever. Just readable code that does what it’s supposed to do.

Common Mistakes Worth Avoiding

A few things I still see often:

  • Using background-color instead of backgroundColor
  • Forgetting the double curly braces
  • Passing a string instead of an object
  • Mixing CSS syntax inside JavaScript objects

These aren’t beginner mistakes. They happen when switching contexts too quickly. Slow down for a second, and most of them disappear.

Final Thoughts

React inline CSS isn’t complicated. It just asks you to think in JavaScript instead of traditional CSS. Once that shift happens, everything lines up.

Use objects. Use camelCase. Keep styles readable. And don’t force inline styles everywhere. React doesn’t expect perfection. It expects clarity.

That’s really it.