Securing Images

Securing URLs adds a layer of security to your images, by blocking anyone who doesn’t have access to your account from altering the URLs. This helps prevent your Sources from being used maliciously—for instance, to produce unwanted renders or as a CDN for a separate site. imgix recommends securing all URLs that are used to serve your images. Although we don’t require that Amazon S3 and Web Folder Sources be secured, it is a requirement for Web Proxy Sources.

To secure an image URL, we use a cryptographic hash function called “MD5” to combine the original URL with a unique token that we generate for each secure Source. The result of this hash function is then appended to the end of your unsigned URL with the s parameter, creating a signed URL.

If the path or parameters of your URL are altered after the s parameter has been set, the altered URL will return a “403 Forbidden” code instead of an image. This prevents unauthorized parties from changing the parameters on your URLs, but it also means that if you need to change the parameters yourself, you’ll need to re-sign the new URL.

Enabling Secure URLs

Before an image URL can be signed, the Secure URL option must be enabled in your Source. Web Proxy Sources have this turned on automatically, and you can turn it on for your Amazon S3 or Web Folder Sources by following these steps:

  1. Click Edit for the Source you’d like to update.

    Screenshot-Edit Source button
  2. In the Security section, click Enabled for the Secure URL option.
  3. Click Continue to Deploy when it appears at the top of the page. Clicking Deploy at the bottom of the following page will complete the changes to your Source.

    Security enabled in dashboard

Now that the Secure URL option is enabled in your Source, image URLs served from that Source can be signed. The Source Tools tab contains the Sign Image tool that will append the signature to the end of the query string. See the next section for instructions on using this tool.

Securing Images on a Per-Image Basis

Once Secure URLs are enabled, you can sign individual images by clicking the Sign Image URLs button on your Source’s detail page.

"Sign Image URLs" button for a secure source

You can also start signing image URLs in the Sign URLs section of the Tools view. Use the dropdown menu to select a source you’d like to use, then click the “Sign URLs” button.

"Sign Image URLs" button for a secure source

  1. Select the domain you’d like to use for this signed URL. You can select from any of your Source’s domains.
  2. Enter the path to your image within your image storage. See the Serving Images guide for more information.
  3. Provide any URL parameters you’d like to apply to your image. See the Image API Documentation for instructions.
  4. Click Sign Image.
  5. The form will be replaced with your signed URL, plus a button to copy the signed URL directly to your clipboard. Use the new signed URL to serve the image.

    Single-Image Signing form

To sign another URL, just click Sign Another Image. If you’d like to sign multiple URLs at once, click the Multiple button in the top right corner, then enter your URLs into the area provided, each on its own line. You can sign up to 100 URLs this way.

Expiring URLs

URLs can be given an expiration date via an Expires parameter that takes a UNIX timestamp in the query string. For example:


This UNIX timestamp translates to 10/30/2016 1:01am (UTC time). Requests made to this URL after that time will output a 404 status code. When the request is made before the expiration date, the Cache-Control header of the image is replaced with the amount of time left until the expiration date, in seconds. With the same Expires value, when the current time is 10/30/2016 1:00am (UTC time), the header will output Cache-Control: max-age=60.

Because the timestamp can be changed freely in the query string, we recommend signing images that use the Expires header to prohibit this behavior.

Securing Images in Your Application

For securing images within applications or websites at scale, we strongly recommend using one of the imgix client libraries. This ensures that you will always be up to date with the latest issues in any given language. Although the imgix URL API is simple, there are a few corner cases that are not always apparent.

If a client library is not available in your language, please see the Securing URLs section of the imgix library blueprint document.

Tips for Additional Security

Securing your image URLs with the methods above gives you one level of security—other people won’t be able to change the parameters you specify. However, doing so won’t prevent hotlinking with the parameters intact. To fend off this type of image theft, it’s best to block such requests at the server level, by only allowing image links from your imgix Source and your website.

Depending on your hosting setup, you may be able to do this through cPanel or another server administration tool (such as editing the policy on your S3 bucket). Alternately, if you’re comfortable changing your .htaccess file directly, here’s a basic recipe you can tweak.

 RewriteEngine On
 RewriteCond %{HTTP_REFERER} !^$
 RewriteCond %{HTTP_REFERER} !^ [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)? [NC]
 RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F]
  • Replace with the name of your imgix Source domain
  • Replace with the domain name of your website (you can add additional lines with this pattern if you have multiple domains requesting images)
  • You can specify some additional settings and experiment with .htaccess using this tool


Can I create a secured custom domain using HTTPS/SSL?

Yes, you can use your own domain name for an imgix URL.

Please contact for implementation details and current pricing information. There are non-recurring fees for setup and changes to the SSL certificate, as well as an ongoing monthly cost.

All standard hostnames powered by imgix (e.g. automatically support secured transport (SSL / TLS) for no additional charge.

How does imgix secure my information?

For account passwords, we rely on industry-standard, high-iteration, adaptive hashing functions to prevent passwords from being readable or reversed.

Billing information such as credit card numbers never touches our servers. Instead, we rely on Stripe to handle our billing, which captures and encrypts billing information using industry-standard best practices.

When you configure a source that has sensitive credentials, such as Amazon S3 keys, we immediately encrypt all private information using hardened, industry-standard encryption algorithms. The few internal services that require access to this information have the necessary access to decrypt the information when required. These services exist within our internal network and are not publicly addressable. As an added layer of security, we recommend to all of our users that they provide us with read-only credentials when working with an image store like Amazon S3.