Is there any way to encrypt HTML server side? Or at the very least, image locations.

I know Zend encrypts PHP...but what about encrypting HTML?

I've seen programs that attempt to obfuscate it by turning it into character entities, or serving it up in fancy JavaScript functions. Frankly, I've never seen a method that couldn't be easily extracted, and for the most part, such systems only end up annoying end users whose systems aren't equipped to handle the obfuscation, instead of annoying wouldbe thieves.

I've come across scripts that allow you to HIDE html code but from what i have learned, many-browsers still display the HTML source and users have alternate-ways to obtain it..

Same case with images URL being hidden, could you point out what is the purpose of it? Given that user's can save the image? Even with robots.txt and html-tages IMAGE-search engines (google, and several others) still index your images and display links in results and cache.

It's true that users can still copy/paste images from their browser...but doing that takes a lot longer than leeching an entire directory of images so it puts some thieves off.

Typical example is a template.

I sell templates. They can steal the HTML code then leech the images by navigating to the image directory after examining the source code.

Anything within html is pretty easy to figure out. You might have slightly better luck embedding the images in flash; of course, then the page becomes unwieldly.

I know Zend encrypts PHP...but what about encrypting HTML?

The huge difference there, is PHP runs on the server so only approved servers have a script's decryption key. Even without encryption, your PHP code is hidden from the user since it's server-side. HTML runs on the client, and there is no way to hide that code. The only reason the World Wide Web works in the first place, is by allowing "view source" to show a page's code. Without that given, the Web simply wouldn't be feasible as an open, public resource -- what would happen if each browser vendor required content authors to use their unique, proprietary algorithm? Also, if source code couldn't be viewed, would the Web have succeeded? I doubt it, since we all learn by analyzing others' code.

The web is all about sharing text files. These text files may contain links to images and other sorts of content, but the whole premise is based on sharing plain text instead of compiled binaries. The concept behind URLs is that every object has a location. If you hide that location, how can the object be accessed? I'm sure you can use some hideous tomfoolery to get around that, like putting the images into zipped PDF files or something, but those PDF files still need to have URLs and those URLs must also be in plain text. The Web is what it is.

The huge difference there, is PHP runs on the server so only approved servers have a script's decryption key. Even without encryption, your PHP code is hidden from the user since it's server-side. HTML runs on the client, and there is no way to hide that code. The only reason the World Wide Web works in the first place, is by allowing "view source" to show a page's code. Without that given, the Web simply wouldn't be feasible as an open, public resource -- what would happen if each browser vendor required content authors to use their unique, proprietary algorithm? Also, if source code couldn't be viewed, would the Web have succeeded? I doubt it, since we all learn by analyzing others' code.

The web is all about sharing text files. These text files may contain links to images and other sorts of content, but the whole premise is based on sharing plain text instead of compiled binaries. The concept behind URLs is that every object has a location. If you hide that location, how can the object be accessed? I'm sure you can use some hideous tomfoolery to get around that, like putting the images into zipped PDF files or something, but those PDF files still need to have URLs and those URLs must also be in plain text. The Web is what it is.

There is a way to have images embedded (say via backgrounds) into the page. From here on it is possible to protect these images being accessed externally (potentialy) by just calling the URL.

Sure, you can configure Apache to disallow hotlinking of images, but this isn't going to encrypt or obfuscate the actual location of the image, it only affects how the images may be accessed. Like Paul said, "Frankly, I've never seen a method that couldn't be easily extracted, and for the most part, such systems only end up annoying end users... instead of annoying wouldbe thieves." Hideous tomfoolery of this sort is security through obscurity, which isn't really security.