Clearshot API screenshot tool

3 Ways to Capture Website Screenshots (Programatically)

When it comes to taking screenshots of websites, you really do have a lot of options. Each of the options have their pros and cons. Depending on your use case and your workflow, some methods may suit you better than others. In this article, I hope to break down all your options for screenshotting live websites and the benefits/negatives of each, so you can make an informed decision.

Although we provide a fully-featured screenshot API here at Clearshot, we will be honestly and fairly evaluating each option available.

Before starting, it’s a good idea to take stock of what you’re looking to achieve, what your current stack looks like and what you’re looking to get from a screenshot service. If you’re reading this, there’s a good chance you want to take website screenshots to use in your application.

Generally, there are 3 main options you can choose from:

Option 1: Use a screenshot API (the simplest & fastest implementation)

Option 2: Use an existing library for your language/framework.

Option 3: Build out your own implementation using a rendering engine wrapper or similar.

Option 1: Use a Screenshot API (the simplest and fastest implementation)

Using an existing screenshot API is generally the easiest way to get started quickly, while also ensuring speed of service and scalability. Implementing an API like this will usually have you making GET or POST requests to the REST API, with the URL you want a snapshot of, along with a range of parameters. You usually have a number of useful parameters to choose from with the most important often being viewport sizing and user agent strings.

You can take a look at our Screenshot API documentation for a list of parameters we support. 

So as for the pros and cons of using a hosted api, let’s have a look…


  • Speed of implementation.
  • Speed of screenshots.
  • Execution of Javascript and support for the latest web technologies.
  • Scalability is taken care of for you.
  • Accurate rendering, usually using a Chromium rendering engine.


  • Don’t control the infrastructure.
  • Have to trust the service provider has service reliability in mind.
  • Usually not free if you’re capturing numerous screenshots.

If you’re wanting to know the best way to evaluate a screenshot api for your development workflow, check out our article on choosing the right api for you.

Option 2: Use an existing library for your language/framework

Using an existing library is another great option. Although it can take slightly more time, you have more control over the setup of the service as well as the hardware you are running it on.

Libraries are available for a range of languages and frameworks; it’s best to look into the best libraries for your specific language/framework.

If you’re running PHP, phpwkhtmltopdf ( is a great library that has a range of options to customise the request and screenshot output.

For JS, dom-to-image ( is battle-tested and works great.


  • Fast setup time.
  • Fast screenshot capture speed (usually).
  • Control over implementation, tech stack and hardware.


  • Render quality is not the best.
  • Javascript execution is either poor or non-existent.
  • Scaling can be difficult.
  • You are responsible for updates to the library and its dependencies.

Option 3: Build your own implementation with a rendering engine wrapper or similar.

This option is really powerful, and is generally what formal screenshot APIs use in the background to provide the service.

Implementing a wrapper library or building an implementation using a rendering engine does not need to be difficult, however it pays to look at the rendering options available to make sure you are maximising compatibility with web technologies, especially Javascript. Chrome/Chromium Headless (and its various implementations) is often the way to go.

You can read more about Chrome Headless here. (

For PHP, puphpeteer ( is useful for this kind of workflow.


  • Great render compatibility
  • Executes Javascript
  • Accurate rendering when compared to a “real” browser.


  • Quite involved to scale up.
  • Render & capture can be slow.
  • May require a custom solution for auto page scrolling, proxies and delay implementation.
  • Ensure latest render engine versions are being used, and the correct dependencies are loaded.

Making your decision

As you can see, you have a range of options to choose from. Now it’s your turn to weigh them up and work out which way you want to go. Often software development decisions are also affected by business-based factors, and offloading technical debt and complexity to an API is a great way to improve your productivity, workflow and application quality.

If you found this article useful and are looking for a simple & powerful screenshot API, we would love to have you on board.

Share on whatsapp
Share on email
Share on linkedin
Share on facebook
Share on twitter