webpage-screenshot captures the whole scroll, then lets you edit the page before shooting it

Full page capture, and why the editing step comes first

The extension is described as an open source extension far beyond typical screenshot capturing, with Save, Edit, Annotate, Print and Share. Its distinguishing capability is stated plainly: it is able to capture 100 percent of both the vertical and horizontal content appearing on any webpage on the Internet.

That is the whole problem it solves. Chrome's built-in capture and most screenshot tools give you the viewport, so a long article comes out as a strip of separate images or gets cut off. This captures the document.

The feature list has one item that tells you this is not a plain capture utility, and it is the one that changes the workflow.

You can edit the page before taking the screenshot, changing any text and titles.

So the extension injects an editing layer into the page first. You modify what is on screen, and then the capture is taken of the edited result. For the use case it was built for, which is archiving or sharing an article, that means you can strip an intrusive header or correct a title before the image goes out, rather than cropping it afterwards.

The rest of the list is annotation and export. You can annotate with rectangles, circles, arrows, lines and text. You can blur sensitive info using the Spray. You can print the screenshot, create a PDF, and create thumbnails. You can save the screenshot on your computer as a PNG file. And you can capture local files, for example from a c:\ path, which is a small feature with an interesting implication for how the capture is implemented.

The primary language is JavaScript, the licence is ISC, and the homepage given in the repository metadata is coltonos.com, which is a different site from the 1CE project the code comes from.

The extension is a fork, and the manifests point back upstream

The package.json is the shortest way to see the history, and it says two things worth knowing before you install anything.

  "repository": {
    "type": "git",
    "url": "git+https://github.com/1click-extensions/1click-webpage-screenshot.git"
  },
  "license": "ISC",

The repository URL points at 1click-extensions/1click-webpage-screenshot, not at the account this code sits in. The package name is superchrome and the version is 1.0.0, and the only dependency is @types/chrome at 0.0.81.

So this is a copy of the 1CE 1Click Webpage Screenshot extension, republished under a different account, and the manifest and metadata still carry the upstream coordinates. The README is the upstream README, with the same installation flow pointing at the 1CE website, the same sponsorship links and the same 1CE branding.

That matters for two practical questions. First, where you actually get the extension from: the documented install path is the 1CE website, then add it to Chrome, and the repository is the source you would build from rather than the distribution channel. Second, what the online storage feature is. The feature list promises unlimited storage for storing your screenshot online, and hosting and sharing unlimited images forever for free, but that is a hosted service belonging to the 1CE product, not a feature of the JavaScript in this repository. The README itself frames the project as another extension of 1CE, with the mission being to advance open-source extensions.

The top level of the repository confirms the shape of the code: a manifest.json, the background page, an editor.html with editor.js, an extension.js, a popup.html, a settings.js, plus css/, js/, libs/, images/ and a _locales/ directory for translations, along with build.sh and a package-lock.json.

Loading it unpacked, and the error message that stops people

There is no packaged build in the repository, so installing it means loading the source as an unpacked extension, and the documentation describes both routes.

The general development flow is three steps. Fork the repo, clone it to your machine, and then drag and drop the file into the Google Chrome browser. The documentation adds a specific troubleshooting note: if you get any error mentioning Apps extensions and user scripts cannot be added from this website, open chrome://extensions/ in a new tab and repeat step 1.

And the install on Chrome for development section spells out the path with more precision. You download the chrome-extension directory, go to chrome://extensions, click load unpacked extension, and choose the directory you downloaded it to.

So the two routes differ in one respect that catches people out. Drag and drop tries to add an unpacked extension by dragging a file into the browser, which Chrome rejects for extensions that have no packaged form, and the error message is about apps, extensions and user scripts. The chrome://extensions route with load unpacked is the one that works, and the repository's own documentation tells you to retry with it.

For an end user rather than a developer, the documented route is the 1CE website and then add it to Chrome. The repository is where the source lives.

The build script at the top level, build.sh, and the presence of a package-lock.json indicate a build step, and the package.json has a placeholder test script that exits with an error and the message that no test is specified. The repository also has a TESTING.md file at the top level, which is where the actual test story is documented rather than in the manifest.

The hosting feature is a service dependency, and the release history is old

Two facts sit awkwardly against each other in this project, and anyone evaluating it should hold both.

The first is the release history. The recent releases list has one entry: v4.5+v14, labelled the SelectionBar plus Webpage Screenshot Release, dated 2014-10-26. The licence line in the README says ISC License Copyright (c) 2018. The last push to the repository was on 2026-07-07.

So the code has been touched, but there has been no tagged release in over a decade. That is not the same as unmaintained, and the repository is not archived, but it does mean there is no versioned artefact to install and no changelog to read for the recent work. The version scheme itself, a base number plus a plus v number, reads like an in-development counter rather than a release line.

The second is the dependency on a hosted service for the most quotable feature. Unlimited online storage and sharing is a 1CE service, and the extension's value proposition includes it. If you install this from source, the question of whether that service still works and on what terms is separate from the code.

The README is also unusually explicit about the funding model, with three separate sections on financial contributions, sponsors and a Patreon link. The stated belief is that everyone can use this extension whether they can pay or not, and the request is a small donation. For a project whose most distinctive feature is a hosted backend, that arrangement is worth understanding before you rely on it.

The description in the repository metadata points at a different product entirely, coltonos.com, described as building a WhatsApp assistant in minutes, and the README ends with a list of unrelated links. So the project has moved on, and what sits in this repository is a snapshot of an extension from a previous life.

Where this extension is the wrong tool

Three cases, and the third is the one most people hit first.

The first is if you need full-page capture of a modern complex site and the extension is from an era of simpler markup. The extension renders the page, optionally edits it, and captures the result. Modern pages with lazy-loaded content, infinite scroll, virtualised lists and embedded media are exactly the case where a naive full-page capture produces a very tall, mostly empty image with the content never loaded. Nothing in the documentation addresses that, and it is a property of how the capture works rather than a setting you can change.

The second is if the hosted storage and sharing is the part you need. That is a service, not a library, and the code in this repository does not contain it.

The third is if you need a maintained, modern capture tool with a full screenshot library. There are well-known alternatives with active release lines, and choosing a decade-old snapshot of an extension whose upstream has moved on means you own any breakage in modern Chrome. The manifest version in particular is the thing to check, because Chrome's extension manifest has changed shape several times since 2014 and an old manifest can fail to load for reasons that have nothing to do with your code.

What the extension is still good for is the editing step, which is unusual and genuinely useful, and the combination of capture plus edit plus annotate plus PDF in one tool without an account.

Editorial conclusion

Adopt this extension if you regularly need full-page captures of long pages rather than viewport screenshots, and you want the ability to edit text before the shot is taken. Do not adopt it if you need an actively maintained tool, because the newest tagged release is v4.5+v14 from 2014 and the code has moved on from the upstream 1CE project it descends from. Verify first what the online storage feature points at, since the unlimited storage and sharing options belong to the original 1CE service rather than to the code in this repository.

Frequently asked questions

Official sources

1. Aminadav/webpage-screenshot on GitHub
2. License: ISC
3. Project website
4. README
5. Releases