I can't remember what site I glanced over and picked up that tidbit, but someone suggested that you should keep PHP parsing to .PHP files, and not modify one's webserver's htaccess to include PHP parsing within .HTML files.

Is this true? Is there any generally agreed upon reason as to doing it one way or the other?

  • 6
    I'm going to answer this question with a question: why would you give a file an .html extension if contains PHP?
    – user16764
    Mar 2, 2012 at 0:36
  • @user16764 Because it's not necessary for end-users to know what language a site is implemented in, and for most people, ".html" is akin to "that internet language".
    – Izkata
    Mar 2, 2012 at 3:47
  • 1
    @user16764, if you want to add a bit of php to existing pages without changing the url, thats certainly the simplest way. Mar 3, 2012 at 6:04
  • 3
    @Izkata: It's not necessary to abuse server-side file extensions in order to hide your development platform from the public. A better way of achieving the same thing would be to use URL-rewriting to hide file extension or replace with the extension of the output format (whether it's HTML, XML, RSS, etc.). For server-side processing, your files should still use the correct file extensions. Mar 3, 2012 at 9:32

6 Answers 6


I'd say there are two major points to consider when making this, or any, programming/configuration decision:

1. Communication:

By default, HTML files are treated as HTML only. Most developers coming into your environment may assume a default configuration. However, if it's a general practice for system admins to change this, then those developers may assume the HTML files may contain PHP.

I believe that leaving HTML files as HTML-only is a great way to communicate to any other developers that page1.html is a pure-HTML file. This can make it easy for new team members to reverse engineer an existing project if this was the configuration used. In this case, there is no need to open the file for editing as one can simply look at the file extension.

2. Could this Create Unnecessary Overhead?:

Let's say you do have several static HTML files. Well, now your PHP server is going to have to parse your HTML files to look for non-existent PHP code. While I'm sure Apache is fast enough to where this isn't a huge, noticeable problem, it's still something to potentially take into consideration.


In summary, my general approach to development is that if it ain't broke, don't fix it. There are a lot of things you can do if you do in fact need to do them, but if you don't have a very strong reason for using non-standard configuration, then it's probably not worth the cost of leaving your potential successor with misunderstandings or confusion.

With that said, I'm not a professional PHP developer, so making HTML files parseable by the server may or may not be considered standard procedure. I would opt to go with whatever is going to be easiest for other PHP developers who join me in my project.

  • I still see the .phtml extension used out in the wild periodically to prevent PHP from parsing purely static content. I asked a client once why they were doing that at all, and the answer was 'So people don't know we're using PHP, because the files don't end in .php!' Indeed, a 'smile and nod' moment if there ever was one.
    – user131
    Mar 3, 2012 at 15:36
  • Funny, people act like it's a deep dark secret.
    – jmort253
    Mar 3, 2012 at 18:25

I would say yes it is true. I don't know how to prove that it is generally agreed upon.

Ideally, all of your .html files have no php code in them, and you should not have the server parse them for php.

If for some reason you did have php code in .html files, then obviously you do need to have them parsed for php. In this case, you should consider changing those files to ".php", but make sure you update any references to them, and make some kind of redirect if their urls were public.

  • +1 - I've seen some servers configured to where there is automatic forwarding of files to the sister file. Like myfile.html. If it's not found, then redirect to myfile.php.
    – jmort253
    Mar 3, 2012 at 18:27

Parsing HTML for PHP tags will create extra overhead. But unless you are talking about a fairly high traffic site, that extra overhead wont have a noticable impact on the performance of the site.

The bigger issue might be maintenance. Will the next guy know there's PHP in those html files? Whether thats a big issue or not would depend on your specific situation.


parsing a .php file to html on server side is just overload to server I/O i think you wanted to ask about caching of web pages (this will reduce network, CPU, RAM load on the server if you have huge number of web requests that your server can't handle)

please have a look on web chaching here


The way I see it, if you have choice, change the file extension to .php, but if you inherit a website and don't want all the addresses to change when you start putting in includes and what-not, then you can either parse php inside html files or use mod-rewrite to fake it. (Since you mentioned .htaccess, I am continuing the assumption of Apache.)

The only time I've run in to trouble with this is that I inherited a site that had XML tags in it, (I really don't know why) and php short tags were enabled, so it tried to parse the XML as PHP. What I did for that was used a search/replace tool to:

//change all the <?XML tags to 

At the time I REALLY didn't know what I was doing. Now I might sometimes know what I'm doing. ;)


I'd say don't change it, use .php.

Creating unnecessary overhead for the server is not the main problem. Maintenance could well be a problem if another guy manages the server upgrades and has no idea to check if .html files have by accident stopped working - everyone assumes it's static.

The core of the problem is security. This little exception in .htaccess could become broken by simply changing level of commands allowed in .htaccess or by AllowOverride None directive anywhere in folders above. If anything like that happens and the php file is not parsed, all your code is instantly visible. All your includes and eventually all passwords could become visible publicly to everyone.. and also it could become cached by search engines.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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