Sorry for such a noob question, I just started learning web development. But I am confuse on how do you handle minification on JS and CSS.

For example you minify your JS, CSS files for release but where do you keep the unminified version of the codebase? Because apparently you only have to release the minified versions of the copy.

Should you have two codebase? Simply because having the minified version only is not something you can work on when debuggging.

And I think having two codebase for the same project is a disaster because you now have to keep everything in sync.

  • 5
    Your released site is not your code base. It is a built artifact from your code base. Apr 8, 2021 at 14:58
  • 1
    Thanks, can you please explain more.
    – jbmcle
    Apr 8, 2021 at 15:46
  • 1
    Your code is what gets minified. Minify mostly removes whitespaces that machines don't need to read but web devs and other people use for readability. You upload your code and your server is configured to serve minified code.
    – keepkalm
    Apr 8, 2021 at 22:44
  • 1
    Are you building a website for the purposes of learning? Or for something official like a personal blog or website for your business? Sep 6, 2021 at 1:25
  • 1
    Old question, but if you're using a CMS, there are plenty of plugins that will minify your CSS/JS files when you publish. This let's you work with the un minified versions, but minifies the versions that users download when they view your page.
    – Trebor
    Sep 6, 2021 at 15:29

3 Answers 3


If it were me, I would have the unminified files that I work on to develop the site. Generally it gets to a point where the CSS and JS are pretty much completed (why would I publish the site if they weren't?) and at that point I would minify them and push the minified files to the server.

My site would only reference the minified files. The unminified files could also be on the server, it doesn't do any harm to have them there and perhaps someone could learn something from any "tricks" included - be generous. As a rule it isn't hard to find the unminified files, the naming convention is generally something like styles.css and styles.min.css.


There are several ways you can implement this as mentioned in other answers, including allowing your CMS to handle everything (perhaps via a plugin), but in all cases:

  • You have a single codebase.
  • You never need to manually edit the minified files as these are generated automatically as part of a "build" process.
  • How you actually link to these minified files can vary.


I thought I would add a minimal (reasonably complete) example that can be implemented easily on Apache (with the help of .htaccess/mod_rewrite) without having to modify any of our existing code.


  • Your original (unminified) CSS and JS files are located in an /assets directory (part of your codebase). Perhaps /assets/css and /assets/js subdirectories respectively.

  • In your HTML source you reference only the original CSS and JS files (as you are doing currently). And these are the only files you manually edit. eg.

     <script src="/assets/js/myscript.js"></script>
     <link rel="stylesheet" href="/assets/css/mystyles.css">

    (We'll use Apache/mod_rewrite later to serve the minified files, without having to change the HTML source.)

  • When you are ready to publish, you run a "build" script that minifies your CSS and JS assets. Your minified files are stored away from your codebase, perhaps in a /minified directory. The contents of which copies the structure of your /assets directory, and to avoid confusion, names the minified files with a min file extension. eg. /minified/css/mystyles.min.css. (NB: As noted above, these are never referenced directly by your HTML source.)

    (The actual method of minification (ie. the scrips to use) I'll leave for the reader to source.)

  • When accessing your site on your development server, only the original (unminified) files are used. And the live site references the minified files. (Although this can be easily overridden, either to access the minified files in development or to access the unminified files on the live site.)

  • Simply deleting the /minified directory will result in the orginal/unminified files being served.

  • Then "the magic"... use Apache mod_rewrite (in .htaccess) to internally rewrite requests for the CSS and JS files in the /assets directory to the corresponding file in the /minified directory, but only if it exists and only on the "live site".

  • Determining the "live site". This can usually be detected automatically, perhaps by checking the requested hostname (eg. www.example.com for the live site and local.example.com for development) or perhaps using some other server trigger (eg. a defined variable in the server config on Apache). For this example, I'll assume that if the www subdomain is requested then we are on the live site.

Summary of the relevant folder structure (after the build script is run):


Then, your .htaccess file in the root of the site would look something like this:

# Set environment variable LIVE_SITE to "1" to access the minified files
# Assume that a "www" subdomain indicates the live site.
SetEnvIf Remote_Host "^www\." LIVE_SITE=1

# To override the above uncomment/edit the following
#SetEnvIf ^ ^ LIVE_SITE=1

RewriteEngine On

# Rewrite any request for CSS or JS "/assets"
# to the corresponding file in the "/minified" directory
# - if on the live site AND the minified file exists.
RewriteCond %{ENV:LIVE_SITE} =1
RewriteCond %{DOCUMENT_ROOT}/minified/$1/$2.min.$1 -f
RewriteRule ^assets/(css|js)/(.+)\.\1$ minified/$1/$2.min.$1 [L]

Additional notes regarding the above .htaccess script:

  • Any level of additional subdirectories are permitted in the /css and /js subdirectories. eg. /assets/css/foo/bar/baz.css.
  • Only .css files can be in the /css subdirectory and likewise, only .js files can be stored in the /js subdirectory. (They just won't be rewritten otherwise.)
  • It's possible that the original (unminified) file does not exist and the minified file is still served (if that exists).

In very general terms (and coming from the perspective of someone who works primarily with TypeScript and JavaScript) a project directory will consist of something along these lines:

  • A src folder containing all the code for the project (checked in to version control)
  • Configuration and utility files used to describe how to build and deploy the product (checked in to version control except for sensitive data like production server keys). Examples of such tools include Webpack, Babel, Grunt, and Gulp.
  • A dist folder containing the files for production (never checked into version control)

All development work takes place in src (or in setting up the build tools). Generally this will involve the use of a server which supports hot reloading so any changes are automatically live in the development environment.

When it comes time to create a production version (be it for deployment to a staging, qa or actual production environment) then it will be built into dist (which might not be locally but on a continuous integration server). This is the stage where any minification is done.

The results of building to dist are then copied to the server and then only used to run in browsers. There's rarely any need to worry about what the specific contents of the files are, only that they behave in the browser the way that is expected. Very occasionally they may be used to debug build problems, but generally they are never looked into and even more rarely edited. They are not checked into version control. If any changes are needed then src is edited and dist is rebuilt using the build tools.

You don't maintain two codebases because the production codebase is generated automatically from the source files (and it is the source files that you maintain).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.