scaturr

I am seeing the same arguments made :) - Watermarking an on-page element does allow the original image to be access quite easily.

However, I will reiterate it is pretty useful to watermark from a user upload. You can watermark an image from the user's local machine - upload it, then display it. All from the client. I don't believe there is any easy in circumventing this method - if there is I would love to see it :)

Yes. Absolutely. The library includes a blob() function for converting a watermarked image to a blob for use with FormData. The site has a demo that does just this for uploading to S3. Any browser supporting File API, FormData, and typed arrays should have no problems. IE 10 is the earliest IE that supports these APIs out of the box, but there are polyfills for IE9. The other modern browsers have supported these APIs for a while now.

Watermarking by urls or existing images would leave the non-watermarked image open - you are correct. This case is still fine for most users, but watermark.js also allows the use of file inputs. You can grab an image from a file input, then watermark, then upload it. This would leave the non-watermarked image closed off to anyone else. This would be handy if you need to generate watermarks in a CMS backend or some other administrative tool

Well what if you batch it in the browser? It is quite possible to use file inputs to generate watermarked images without ever storing the image you are watermarking, and then upload the result.

You are correct. This would serve the purpose for many users who don't know how to go digging around for urls in JS, but more importantly its a tool for generating them on the client so a server doesn't have to - say for a CMS?

How so? Being able to generate watermarks in the browser is one less thing a server has to do right? Especially if that server is in a shared environment without image libraries or lacks tools for uploading things concurrently.