Free · Fast · Privacy-first

Convert CSS from Production to Development Format

When you inherit a project that has only a minified production CSS file, converting it to a properly formatted development version is the first step toward maintainable ownership.

⚡

Converts minified production CSS to a properly formatted development file

🔒

Output suitable for committing to version control as a source file

✨

Each rule and property on separate lines for readable diffs in pull requests

⚡

Instant browser-based conversion, nothing uploaded to a server

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Unminifier Beautifier to your website

Drop the Unminifier Beautifier into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/css-tool/unminifier-beautifier?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Unminifier Beautifier by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/css-tool/unminifier-beautifier?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Unminifier Beautifier by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Creating a Development Stylesheet from a Production CSS File

A project without a CSS source file is a project that cannot be safely maintained. When only the minified production CSS exists, any edit to that file is a manual operation on a dense compressed string with no whitespace to guide you and no diff tooling that produces readable output. Committing the minified file to version control produces useless diffs where any change appears as a replacement of thousands of characters on a single line. Converting the minified CSS to a formatted development file solves both problems: the formatted file is editable, and future edits to it produce readable line-by-line diffs that make code review possible.

The conversion workflow is straightforward. Copy the minified production CSS from the server, a build output directory, or a browser Network tab. Paste it into FixTools and convert it to formatted output. Save the formatted file as the new source stylesheet in the project repository. From this point forward, all edits happen in the formatted source file. The build pipeline minifies the source before deployment. If no build pipeline exists, add a simple minification step using FixTools or a CLI tool before deploying changes.

The formatted output from the conversion will reflect any semantic optimisations applied by the minifier: merged selectors, normalised values, shorthand consolidations. If you know the original source had specific structure that the minifier altered, you may want to reorganise the formatted output after conversion. Add section comments to identify groups of related rules, split merged selector groups back into individual rules, and restore longhand properties where shorthands were combined. This additional cleanup turns a recovered file into a maintainable source file rather than just an expanded version of the production output.

Once the new source file is committed, Prettier should usually be added to the project workflow even if you do not adopt every Prettier convention. Prettier produces deterministic output that eliminates style debates during code review and ensures every developer sees identical formatting after save. The conversion gives you a structurally sound starting point; Prettier enforces ongoing consistency. Configure printWidth, tabWidth, and useTabs in a .prettierrc at the project root, then run Prettier once over the converted file to bring it in line with project defaults before committing. From that point forward, a pre-commit hook running Prettier prevents the gradual drift that always accumulates in long-lived stylesheets when each developer formats by hand. The combined workflow (FixTools for recovery, Prettier for maintenance) gives you both a clean starting state and a durable enforcement mechanism without manual style policing.

MDN Web Docs: CSS Syntax Git Documentation: gitignore

How to use this tool

💡

Paste a minified production CSS file. The output is a formatted development-ready stylesheet with each rule block properly indented and each property on its own line, structured the way a developer would write it for ongoing maintenance in version control.

How It Works

Step-by-step guide to convert css from production to development format:

1
Obtain the production CSS file
Copy the minified CSS from the production server, build output directory, or browser Network tab. This is the file you will convert to a formatted development source. Note the file name, URL, or version as a reference.
2
Convert to development format in FixTools
Open FixTools CSS Unminifier, paste the minified content, and click Unminify. The formatted output is the development-format version of your production CSS, with each rule and property properly indented.
3
Clean up and organise the formatted file
Copy the output to a text editor. Add section comments to identify logical groups of rules. Split any merged selector groups back into individual rules if needed. Add a file header comment with the conversion date and source reference.
4
Commit as the source file and set up a build step
Save the cleaned-up file as the project source CSS (for example, src/styles.css). Commit it to version control. Set up a build step that minifies this file to the production output (dist/styles.min.css) before deployment. Update .gitignore to exclude the minified output if appropriate.

Real-world examples

Common situations where this approach makes a real difference:

Taking over a project with only compiled assets

A developer inherits a project where the CSS exists only as a 120KB minified bundle in the public directory. There are no source files, no build configuration, and no documentation. They copy the minified bundle, convert it to development format using FixTools, and save it as src/styles.css. They add a build script using cssnano CLI to regenerate the production bundle from the source. The project now has a maintainable CSS source file and a reproducible build process where there was none before.

Establishing CSS source control for a legacy site

A company has run a website for eight years with CSS edited directly in the production minified file. No version control has been used for CSS changes. A new developer joining the team converts the production CSS to development format, breaks it into five logical files by feature area, and commits all of them to a new Git repository. The team now has CSS history, code review capability for CSS changes, and a clear separation between the source files and the production build.

Preparing a CSS handoff from one agency to another

An agency is handing off a website to a client's in-house team. The site CSS exists as a minified bundle. The outgoing agency converts the production CSS to development format, organises it into sections with comments, validates it, and includes it in the handoff documentation. The client's team can immediately begin reading, understanding, and maintaining the CSS rather than working blind with a minified file.

Creating a development version for a staging environment

A developer needs a staging environment where CSS changes can be tested and reviewed before production deployment. The production site has only minified CSS. They convert the production CSS to development format and deploy it to the staging environment. Now CSS changes made in staging produce readable diffs in pull requests, making it straightforward for the team to review exactly which rules changed before approving a deployment.

Pro tips

Get better results with these expert suggestions:

Create a build script even for simple projects

Once you have a formatted source file, add a simple build step to your deployment process. A one-line npm script running cssnano or clean-css via their CLI takes minutes to set up and ensures the production CSS is always generated from the source. This prevents the future situation where the source and production files drift out of sync because someone edited the minified file directly.

Establish the formatted file as the canonical version with a README note

After converting and committing the formatted source, add a note to the project README or a comment at the top of the CSS file explaining that this is the development source and the minified production file is generated from it. This prevents future contributors from treating the production file as the source and losing their changes at the next build.

Split large converted files into logical modules

If the converted production file is very large (over 1,000 lines), consider splitting it into separate files by concern: typography.css, layout.css, components.css, utilities.css. Concatenate and minify these files as part of the build step. Smaller, focused files are easier to maintain and produce more readable diffs per change.

Version the conversion date in a header comment

Add a comment at the top of the newly created source file noting the date it was converted from the production file and the production URL or file path it was converted from. This provides useful context when someone later needs to understand the file's origin.

Add minified files to .gitignore after creating a source file

Once you have created a formatted source file and set up a build step to generate the minified output, add the *.min.css pattern to .gitignore. This prevents the minified file from being committed alongside the source, avoiding confusion about which file is the authoritative source of truth.

Organise the converted file into sections with comments

After converting, manually add section comments to the formatted file: /* Layout */, /* Typography */, /* Components */, and so on. This organisation makes the file maintainable and helps future contributors understand the structure at a glance.

Run the formatted file through a validator before committing

After converting and cleaning up the formatted file, run it through the FixTools CSS Validator before the first commit. Confirm there are no syntax errors before establishing this as the project source file. Introducing an error-laden source file is worse than having no source file.

FAQ

Frequently asked questions

Editing minified CSS directly is error-prone and produces unusable diffs. A single character mistake in a minified file is nearly invisible and can affect hundreds of rules. When the file is committed to version control, a change to a minified file appears in diffs as a replacement of thousands of characters on a single line, making code review meaningless. A formatted development file produces line-level diffs that show exactly which rule and property changed. This makes both editing and reviewing CSS changes safe and auditable.

Not exactly. The conversion restores whitespace formatting but cannot recover information that was discarded during minification. Comments are gone. Any value transformations applied by the minifier (colour shortening, zero unit removal, shorthand consolidation) remain in their optimised form. Selector merging from cssnano remains. The converted file is functionally equivalent to the original source and fully readable, but it reflects the minifier's optimised representation rather than the original developer's authored representation.

The simplest approach is the cssnano CLI. Install it with npm install --save-dev cssnano cssnano-cli, then add a script to package.json: "build:css": "cssnano src/styles.css dist/styles.min.css". Run npm run build:css before deploying. For more complex setups, add CSS minification as a PostCSS step in webpack, Vite, or Parcel. Any of these approaches ensures the production CSS is always generated from the readable source file, preventing the source and production files from drifting.

Add the minified output file path to .gitignore, for example dist/styles.min.css or public/css/*.min.css. This prevents the generated file from being committed alongside the source. The source file (for example src/styles.css) should be tracked and committed. The build step regenerates the minified output during deployment. If other developers need the minified file locally for development, they run the build step after cloning the repository.

After converting the bundle to development format, identify the logical sections within the file. Look for abrupt style transitions (from reset styles to component styles, for example) and any preserved licence comments that mark file boundaries. Split the formatted file into separate logical modules. Create a main CSS file that imports the modules in the correct order (or configure your build tool to concatenate them). This modular structure is easier to maintain than a single large file, even if the original bundle was a single file.

Yes. After converting, adjust the indentation style to match your project's CSS conventions. If your project uses four-space indentation but the converted file uses two-space, run the file through the FixTools CSS Formatter or your editor's formatter with the project-standard settings. Consistent indentation across all CSS files in a project reduces friction when switching between files and produces cleaner diffs where indentation changes do not appear as content changes.

CSS errors in the converted file originate from errors that were already present in the production CSS. Minifiers do not introduce errors; they may mask them by reducing the amount of code to inspect. Fix each error in the formatted source file, then rerun the validator to confirm. After all errors are resolved, run the build step to generate a new minified production file. The corrected production file may behave differently if the errors were previously causing unexpected cascade behaviour.

Even for short-term maintenance, a formatted source file reduces risk. A single character mistake in a minified file is nearly impossible to spot before it reaches production. A formatted file with readable rules makes mistakes visible during editing. The conversion takes under a minute. The time saved by avoiding even one production CSS mistake more than justifies the conversion, regardless of how short the maintenance period is.

Preserve them initially, then audit them as a separate cleanup step. The conversion faithfully reproduces every -webkit-, -moz-, and -ms- variant from the production file, and removing them blindly during the conversion risks breaking layouts for users on browsers you intend to support. Once the new development file is committed, configure Browserslist with a modern target and add Autoprefixer to the build step. Run the build, compare the new production output against the old one, and confirm no required prefixes were dropped. Then remove the prefixes from the source file; Autoprefixer will re-emit only the ones the current Browserslist target actually needs. This two-phase approach (preserve, then audit) keeps the conversion safe and lets the build pipeline manage prefixes going forward, which is where prefix management belongs.

Set up the build step to emit a source map alongside the minified output. With cssnano CLI, pass --map to generate a .css.map file. With PostCSS via webpack, set devtool to source-map in webpack configuration. With Vite, source maps for CSS are emitted by default in development mode and can be enabled in production via build.sourcemap. Once the map is emitted and served from the same path the sourceMappingURL comment references at the bottom of the minified file, DevTools will show your new development file in the Sources panel when debugging on the deployed site. This restores the workflow where you click on a rule in the Styles panel and DevTools opens the authored source location, which is the productive end state after recovering from a no-source situation.