Images.weserv.nl is an image service that is free for use to anyone, and we offer it as-is, it's just basic
image resizing, available to anyone, easy to use. We try to keep everyone as happy as we can.

The project started around 2007 on some spare servers. It was targeted at customers, to be used in
websites, web applications and mobile applications. By making it freely available, it saved traffic (through
compression) and offloaded the main servers, because customers didn't have to use poor self-written
scripts for image resizing. We gained experience with different user cases, and the separation from the
main servers enabled us to use the latest and greatest software stack.

Since 2011 images.weserv.nl is privately funded, and used as a testbed for new techniques in resizing,
recognition and processing. Operating costs of the image service are very low. To prevent conflicts of
interest, we never accepted any (financial) compensation or donation since we started, and we don't
affiliate. Our intent is to keep the service running for many years to come.

Try it for yourself, if you experience problems or if it doesn't meet expectations, contact us.

There is a filter on the origin domain name. This means that we refuse to download images from certain
websites, to prevent our service from being blocked by others. This filtering is handled by OpenDNS
domain tagging.

Furthermore, there is a request limit, which is 700 images per 3 minutes, after which the IP-address will
be blocked for 1 hour.

We are not a fan of filtering or limitations, but even more so, we are not a fan of being filtered. It is
always possible to use our open source code, without filtering and limitations, on your own server.

Sure, the BSD 3-Clause license permits you to use our code in your product, but please don't use our
name in your marketing materials. Using the free service provided on images.weserv.nl in your products
is also permitted, but be reminded that our support is best-effort.

If you really mean to sell our free service to other people as-is; I guess you're an amazing salesman, or
we are terrible at it, but we do enjoy some good competition!

Yes, we do, for 7 days, after which they will be deleted automatically. The log is kept only on the server
that processes your request. We don't share these logs, or store them in any other place. More
information on how we collect, store and use any data, can be found in our privacy policy.

We've started this service in 2007, use Cloudflare since early 2012, and are on the free-tier since 2015.
Costs for the servers to support images.weserv.nl are really low, and it serves as a great testbed for new
technologies. Cloudflare is based on the same principles to provide their services.

Uptime guarantees buy you nothing but expensive insurance policies. We've had 99,993% uptime on
average since 2007, all based on best-effort from all sides. Our service will not be the best fit for
everyone: if you need more guarantees, anything besides best-effort, we encourage you to use our
config and code as provided on our GitHub, and build your own solution. We're always happy to help
with questions that may arise if you do so.

Besides, our service is free, so there is nothing to pay you back. If you want to help us, please do so by
reporting any bugs, problems, and/or reviewing our code!

Due to privacy concerns we're unable to share names, even if we were able to do so technically.

Our service is mainly used by ISP's, dealerships, real estate agencies, shops, social networks and mobile
app developers. Our reach is global, and we fetch images from 300.000 different unique domains.

We don't send any details to the server where the original image is kept. All requests for the original
image are done anonymously from our servers. The only two things the request from our server has in
common with your request is: 1. the address of the original image, and 2. the time you make the request.

The only exception is if there is a technical oddity in an image which causes strange behavior on our
server(s). If you ask us to process such an image, we may try to copy the technical bits that causes the
strange behavior. But we will never show others any (real) part of your image.

Your images are private, and will not be shared, unless you tell us so. Other people can always use the
same link (web address / URL) as you use, but we will not share any web addresses or logs.

But please, always be careful of what you put on the internet, and who you trust online. If you don't trust
our servers, or Cloudflare, you can use our open source code on your server(s).

# If images are modified, do you refresh them after a certain period of time?

A cache is a place where data (such as images) is temporary stored, to improve performance when the data
is requested again. If the data is requested again, it may be served from the cache. For this service,
the most important bits are our server cache, and your browser cache.

For added security we use HSTS to let modern browsers know that they can and should use HTTPS, we
don't send any redirect headers ourselves, this is being done by your browser. It prevents any
opportunistic MITM attacks.

GZip compression is disabled, because it increases file sizes for JPEG-images, and it increases CPU-load
on client and server.

JPEG-compression is honored, and is by default used when requesting BMP-images (they are converted
to JPEG). If you want to modify compression for JPEG-images, you can do so by setting the &q=
parameter.

We support animated WebP and GIF images through the use of &n=-1. By default the first frame of
each image is processed. We don't support APNG, since the official libpng reference implementation
doesn't support this extension.

# Can I use my own (sub)domain? E.g. by using a CNAME to images.weserv.nl?

We offer this service only on the images.weserv.nl domain, and we offer it as-is. However, if you want to
use it under your own (sub)domain, please see check our GitHub to use it on your own server(s).

The goal of this service is reaching out to starting websites that don't have the skills nor resources to
script and host something themselves. But we don't want to serve the whole internet, aside from the
amount of traffic (we already handle millions of requests per hour, which is great), our opinion is that
when sites grow, they probably want to host their own solution. This solution will probably integrate
better with their site(s), and will offer many advantages we just can't.

# Why am I not seeing any HTTP 304 header when I request a cached image?

We disable 2 (default) settings regarding to cache-control. These are the ETag header, and the Last-
Modified header.

We do set the Cache-Control header. Allow me to explain this decision, using Apache-config.
(Images.weserv.nl uses nginx on all servers, but Apache is more common for most people, and we
did use Apache in 2011)

Consider the following Apache settings, these are identical to the nginx-settings we use:

The first two rules disable ETags completely, so the browser is somewhat forced to listen to the Cache-
Control header. The last rule tells the browser to cache the file 31536000 seconds, or 1 year.

Optional, we use multiple servers to serve static content, and we are not sure about the last-modified
times those servers report, because each has his own version of the cache, so we also use:

Header unset Last-Modified

It tells Apache to not serve any Last-Modified headers, so browsers can only listen to the Cache-Control
max-age header.

These settings are used by us on lots of high-traffic websites, and disabling of ETags and Last-Modified
headers sure helped to drive traffic down to one fifth of what it used to be. Especially Internet Explorer is
very sensitive to those settings.

Disabling Last-Modified will stop browsers from asking 304 Content Not Modified requests. In my
experience this is positive, because the webserver has less requests to process, and browsers rely more
on the Cache-Control settings you serve. But it may or may not suit you. Some browsers will try to
validate assets every few minutes if you serve them a "Last-Modified" header, and that's why I would
advise to disable the use of it completely.

If you want more information about the headers we serve, consider using REDbot.org this will explain
every header we serve, and why this is used. We also serve Cache-Control: public, this allows browsers to
cache things even when accessing images.weserv.nl over https://.

Let us know if you need more info. We are open for comments about the caching policies we use. We do
run complete tests on server load, bandwidth, and CPU-cycles, for each header we place. Enabling 304
will generate 5 times more requests from browsers in our case, this could be different for your site, but I
expect it to be the same.

That means you're unique, and one of a kind! Did you also read our documentation?

If your question is not within these frequently asked questions, or if there is still something not clear;
Please open an issue on our GitHub. We do our best to answer all questions, and we may even honor
your question by featuring it on this page!