[scaturr]

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.

[Drakim]

Anything that happens client-side is out of your hands.

An potential image thief could just make his browser not run the watermarking function if he wanted. What we are essentially doing here is handing the image thief an image, and then handing him a watermark, and then telling him to watermark the image himself (with no guarantee that he will actually do so).

[0xff00]

It defeats the point of watermarking since someone with the technical skills can just recover the non-watermarked image.

[scaturr]

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

[austinsmorris]

I think the point is to create watermarked images in the browser for later use. Once that's done, you only show users the watermarked version. This is for administrative use, not end-user presentation.