CSS Portal

CSS to JavaScript Object

Moving styles into JavaScript - for React's style prop, styled-components, or any JS-in-CSS workflow - usually means hand-converting every kebab-case property to camelCase and wrapping each value in quotes. It's tedious, and it's easy to miss a property or mistype a vendor prefix along the way.

This tool does that conversion for you. Paste in a stylesheet, or just a few declarations, and it converts as you type: each selector becomes a JavaScript object with properly cased keys and quoted values, ready to drop straight into your code. Everything runs locally in your browser, so nothing you paste ever leaves this page.

☕
Enjoying this site?

Help keep it running with a small coffee donation. Every bit of support is appreciated!

Buy us a coffee

CSSInput

JSObject

About this converter

A closer look at how the conversion works, what it's suited for, and where its limits are.

How it works

The parser reads your CSS the way a browser does: it understands comments, quoted strings, url() values (including data URIs with semicolons), nested rules and at-rules. Each selector in a comma-separated list gets its own entry, and a selector that appears twice is merged into one entry, with later values winning just as they do in CSS.

Every property name is converted from kebab-case to camelCase following the same convention React uses internally: background-color becomes backgroundColor, and vendor-prefixed properties like -webkit-transform become WebkitTransform (capitalized prefix), while -ms-transform becomes msTransform (lowercase, matching the historical Microsoft exception).

Values become quoted strings, with backslashes and quotes escaped so the output is always valid JavaScript, and values spread over several lines are joined onto one. With Numbers as numbers on, plain numeric values like z-index: 10 or opacity: .5 are written as JavaScript numbers instead. Choose One flat object to get just the declarations, ready for React's style prop.

Where it's useful

  • Migrating a legacy CSS file into a React style object or a JavaScript theme file
  • Converting a component's styles for CSS-in-JS libraries that expect object syntax
  • Quickly inspecting how many rules and properties a stylesheet contains
  • Generating a starting point for design tokens stored as JS objects

Good to know

  • @media, @keyframes and nested rules are skipped by default, and the status line tells you what was left out. Turn on Keep @media & nesting to keep them as nested objects for CSS-in-JS libraries.
  • Repeated properties, such as a -webkit-box fallback before display: flex, are merged because an object can't hold the same key twice. The last value wins, and you get a warning.
  • Errors such as a missing } or an unclosed string are reported with their line number.
  • Nothing you type is transmitted anywhere. Conversion happens entirely in JavaScript running in your browser tab.

Frequently Asked Questions

What is a CSS to JavaScript object converter?

A CSS to JavaScript object converter transforms standard CSS declarations into the object syntax used by JavaScript frameworks and CSS-in-JS libraries. It converts property names from kebab-case (e.g. background-color) to camelCase (e.g. backgroundColor), and wraps values in quotes so they are valid JavaScript strings. The result is a plain JavaScript object you can drop directly into React's style prop, a styled-components theme, or any other JavaScript-driven styling system.

How do CSS property names change when converted to JavaScript?

CSS uses kebab-case for property names, where words are separated by hyphens - for example font-size, background-color, or border-top-width. JavaScript object keys cannot contain hyphens without being wrapped in quotes, so the convention is to convert to camelCase instead: each hyphen is removed and the letter that followed it is capitalised. So font-size becomes fontSize, background-color becomes backgroundColor, and border-top-left-radius becomes borderTopLeftRadius.

How are vendor-prefixed properties converted?

Vendor-prefixed properties follow a slightly different convention. The -webkit- prefix becomes a capitalised Webkit, so -webkit-transform becomes WebkitTransform. The -moz- prefix becomes Moz, so -moz-appearance becomes MozAppearance. The -ms- prefix is the historical exception - it stays lowercase, so -ms-transform becomes msTransform rather than MsTransform. This matches the convention React uses internally for inline styles.

How do I use a converted CSS object in React?

In React, inline styles are passed as a JavaScript object to the style prop rather than as a CSS string. After converting your CSS, assign the resulting object to a variable and pass it to the element:

const styles = { backgroundColor: 'red', fontSize: '16px' };
<div style={styles}>Hello</div>

Alternatively you can inline the object directly: <div style={{ backgroundColor: 'red' }}>. Note that React expects values to be strings (or numbers for unitless properties), which is exactly what this converter produces.

Should CSS values be strings or numbers in a JavaScript style object?

Most CSS values should be quoted strings in a JavaScript style object - for example fontSize: '16px' or color: '#333'. The exception is unitless numeric properties such as z-index, opacity, line-height (when unitless), and flex. These can be expressed as plain JavaScript numbers: zIndex: 10 or opacity: 0.5. React and most CSS-in-JS libraries accept either form for unitless properties, but will not automatically append px to string values - that must already be part of the string.

What happens to @media and @keyframes rules during conversion?

A flat style object, such as one for React's style prop, cannot hold @media, @keyframes or @supports, so by default they are skipped and the status line tells you how many. Turn on Keep @media & nesting to keep them as nested objects with keys like '@media (max-width: 600px)' and '&:hover'. That is the object format used by CSS-in-JS libraries such as Emotion, JSS and MUI's sx prop. One-line at-rules such as @import and @charset have no object form and are always left out.

Can I use this converter for styled-components or Emotion?

Partially. Both styled-components and Emotion primarily accept template literals with standard CSS syntax, so you do not usually need to convert to object syntax for basic usage. However, both libraries also support object syntax, which is where this converter is useful - particularly for migrating existing stylesheets into a JS-in-CSS workflow, or for generating theme objects and design tokens. Turn on Keep @media & nesting and nested selectors, @media and @keyframes blocks are kept as nested objects, which both libraries understand.

What is the difference between CSS-in-JS and inline styles in React?

Inline styles in React are passed directly via the style prop as a JavaScript object and are applied as element-level styles with no class generation. They have some limitations: they cannot target pseudo-classes like :hover, pseudo-elements like ::before, or apply media queries. CSS-in-JS libraries like styled-components, Emotion, or vanilla-extract generate real CSS classes at runtime or build time, which means they support the full range of CSS features including pseudo-selectors, at-rules, and theming - while still letting you write styles in JavaScript.

Is my CSS processed server-side when I use this tool?

No. All conversion happens entirely in your browser using JavaScript. Nothing you paste into the tool is sent to any server. This means it works offline once the page has loaded, and there is no risk of sensitive stylesheet code being transmitted or logged anywhere.

Should the keys be camelCase or the original CSS property names?

Use camelCase keys, such as backgroundColor, for React's style prop and most CSS-in-JS libraries. Choose CSS names to keep the original property names, quoted, such as { 'background-color': 'red' }. Some libraries accept those too, and they are handy for design tokens or for passing to element.style.setProperty(). The separate Quote every key option only adds quotes around keys that do not need them, for code styles that prefer consistent quoting.

☕
Enjoying this site?

Help keep it running with a small coffee donation. Every bit of support is appreciated!

Buy us a coffee