Security Whitepaper

This document explains how GetWebP handles image bytes, local state, and network traffic across the web converter, Chrome extension, CLI, MCP server, and WordPress plugin.

It is based on the shipped code and documentation in this repository as reviewed on July 1, 2026. It is intentionally specific about scope: this whitepaper separates the image-processing data plane from the website, licensing, account, and service-credit control plane. It is also intentionally conservative about implementation detail: the goal is to document stable security properties, not transient internal wiring.

Executive Summary#

• Image conversion is local across every GetWebP product. There is no GetWebP-operated upload endpoint for image bytes.
• "Your bytes never leave your device" applies to the image-processing data plane. It does not mean the marketing site, dashboard, or license system are zero-network services.
• The converter products do not ship analytics, telemetry, or crash-reporting SDKs.
• License activation, status checks, silent renewals, and account operations do generate network traffic, but that traffic is control-plane metadata rather than image content.
• The current free WordPress plugin encodes in the administrator's browser and saves through same-site WordPress admin requests. The GetWebP service handles account, credit, and job metadata only.
• The Chrome extension may fetch the source image from its original website when you invoke conversion on a remote page, but it does not relay that image to GetWebP.

Scope and Terminology#

This whitepaper covers:

• Where image conversion executes
• Which product surfaces can make outbound network requests
• What is stored locally
• What data GetWebP does and does not receive
• Product-specific security boundaries and residual risks

This whitepaper does not claim:

• That your own device, browser, WordPress host, CDN, or object storage is secure by default
• That local execution eliminates all decoder, browser, or operating-system vulnerabilities
• That the marketing site and dashboard are "offline" or "zero logging"
• To provide legal advice; compliance implications depend on your deployment and jurisdiction

Security Boundary: Data Plane vs. Control Plane#

The key design decision in GetWebP is the separation between the image-processing path and the product-control path.

If a statement in this document says "no upload" or "local-only," it refers to the data plane unless stated otherwise.

Product Matrix#

Web Converter and PWA#

The web converter runs inside the user's browser and uses the local conversion engine directly. There is no server-side image-processing hop in the normal conversion flow.

What this means in practice:

• Image files selected in the converter are processed in-browser.
• The Progressive Web App can work offline after its assets have been cached locally.
• There is no image-upload endpoint to GetWebP for browser conversion.
• Cookie consent and minimal website preferences are stored locally in the browser.

Important boundary:

• The website itself is still a normal website. The repo contains cookie consent flows, OTP-based auth/dashboard flows, and privacy/GDPR pages that explicitly describe website-operation data such as IP address, browser information, page visits, and necessary security logging.
• Those website operations are separate from image conversion. They do not imply that image bytes are uploaded, but they do mean the site is not a "zero-network" property in the absolute sense.

Chrome Extension#

The Chrome extension uses Manifest V3 and ships its conversion logic inside the extension package. It does not fetch remote code at runtime for conversion.

Permission surface#

Equally important are the permissions the extension does not request: no browsing history, no bookmarks, and no password-manager permissions.

Local state#

The extension stores user preferences and local license state in browser-managed extension storage. For paid use, this includes the signed local license token, the local license credential needed for renewal, and renewal-warning state used by the background alarm flow.

Pro status is derived from the signed token rather than a plain stored boolean. That reduces the risk of trivial local flag tampering.

Network behavior#

Two different network cases matter:

1. Source-image fetches from the original site When the user right-clicks an image on a webpage, the extension may fetch that image from its original origin so the browser can read the bytes locally. That is browser-to-origin traffic, not an upload to GetWebP.

2. License control plane If the user activates or renews a paid license, the extension calls the GetWebP license service and stores the returned signed token locally.

So the strong claim is:

• The extension makes zero GetWebP conversion uploads.
• It does not make zero network requests in every possible extension workflow.

CLI and MCP Server#

The CLI is the clearest local-only deployment model in the product line: it reads files from disk, converts them in memory, and writes outputs back to disk.

CLI guarantees#

The CLI security document and shared facts for the repo make the following guarantees explicit:

• Image bytes are never uploaded
• File names, directory paths, and folder structure stay local
• Conversion settings are not reported to a server
• No analytics, telemetry, or crash-reporting SDKs are present
• Day-to-day conversion works offline after activation

CLI control plane#

The CLI does contact the GetWebP license service for:

• activation
• status
• logout / device unbind
• a lightweight heartbeat used for license-state checks

That traffic is license-related metadata only. It is not image content.

Device identity and local storage#

The CLI binds a Pro license to a device using a one-way hash of a machine identifier. It stores its local license state in an encrypted config file and verifies the license token offline using an embedded public key.

MCP server boundary#

The MCP server is not a cloud API. It is a local stdio server that imports the same conversion core used by the CLI. In practical terms:

• the LLM client talks to a local MCP process
• the MCP process converts files on the same machine
• the MCP server reuses the CLI credential store for licensing
• its network surface is therefore the same control plane as the CLI, not a separate image-upload service

WordPress Plugin#

The WordPress plugin has a different execution model from the web converter, extension, and CLI products, so its boundary needs to be stated precisely.

Where processing happens#

The current free plugin processes images in the administrator's browser:

• the WordPress admin page scans eligible Media Library attachments
• the administrator's browser downloads source files from the same WordPress uploads context
• WebAssembly workers create WebP and optional AVIF outputs
• generated files are posted back to the same WordPress site through authenticated admin requests
• WordPress stores generated files in uploads and records attachment status

GetWebP does not receive the site's image bytes, decoded pixels, or generated files. Image data may still appear in the site's own logs, backups, object storage, CDN, or hosting stack depending on how the site is configured.

Service account and credit behavior#

The free plugin calls the GetWebP service for:

• connection intent and authorization
• service token validation and status
• credit availability and reset timing
• job preparation, completion, and refund
• disconnect actions

Those calls may include site/account token state, site URL, plugin version, local attachment IDs or source keys, source MIME type, byte size, width, height, requested outputs, preset, run mode, idempotency keys, and job lifecycle status.

Local storage#

The plugin stores settings, service connection state, generated-file paths, attachment status, statistics, and run history in WordPress options and attachment metadata. Generated WebP and AVIF files are stored in the customer's uploads directory.

The Pro add-on, when installed, has separate license, queue, and delivery state.

Delivery behavior#

The free plugin uses standard WordPress HTML and srcset filtering to serve generated WebP files where WordPress can replace attachment image URLs. It does not write .htaccess or Nginx rewrite rules, and the standard free delivery path does not automatically serve AVIF on the frontend.

Data GetWebP Does Not Collect for Conversion#

Across the product line, the documented and code-backed anti-facts are:

• no image uploads to GetWebP-operated services
• no conversion telemetry
• no analytics SDKs inside the converter products
• no crash-reporting SDKs inside the converter products
• no per-conversion reporting of filenames, paths, file sizes, or settings from the CLI / MCP flow
• no WordPress image-byte uploads to the GetWebP service-credit flow

This is why the security model is best described as structural: the products avoid creating a server-side image-retention problem in the first place.

Data That May Still Be Processed#

GetWebP does process some non-image data when the relevant features are used.

None of those categories are image uploads, but they are still part of the broader service footprint and must be accounted for honestly. The WordPress service-credit flow may report bounded attachment metadata and preset/output choices, but not original image bytes, decoded pixels, or generated files.

Compliance Posture#

GetWebP's architecture materially simplifies privacy review for image content because image bytes do not traverse a GetWebP-controlled processing backend.

The strongest accurate compliance statement is:

• For local image processing, GetWebP acts as software provider rather than remote processor of the image content.
• For website, licensing, account, and billing flows, GetWebP still operates normal web-service surfaces that process limited operational and account data.

So the correct enterprise reading is not "GetWebP processes no data at all." It is:

• "GetWebP does not process your image content on its own servers."

That distinction matters for GDPR, CCPA, procurement review, and internal security questionnaires.

Integrity and Hardening Notes#

Several integrity properties are product-specific:

• Chrome extension: Manifest V3 package, bundled runtime code, extension CSP declared in the manifest
• CLI: SHA-256 checksum workflow for releases and offline signature verification of license tokens
• MCP server: local stdio execution and direct import of the CLI core rather than delegation to a hosted image API
• WordPress plugin: privilege checks around admin actions, WordPress nonce and capability checks, same-site admin saves, and bounded generated-file cleanup

This whitepaper intentionally does not make stronger claims than the repo supports. For example, it does not claim formal third-party audits, SOC 2 coverage, or universal website CSP hardening where the implementation evidence is not present here.

Residual Risks and Non-Goals#

No local-first design removes every risk. The important residual risks are:

• Compromised endpoint: if the user's browser, desktop, or WordPress host is compromised, local processing does not protect against local theft.
• Decoder vulnerabilities: WebAssembly and browser sandboxing reduce exposure, but they do not eliminate the possibility of image-parsing bugs.
• Third-party origin visibility: the Chrome extension may fetch a source image from the site that already hosts it; that origin can still observe the request.
• Customer infrastructure copies: WordPress hosting stacks may create backups, logs, or cached copies outside GetWebP's control.
• Normal website threat model: dashboard auth, cookies, billing, and support remain standard web-service surfaces and should be reviewed as such.

Disclosure and Related Documentation#

Security reports: security@getwebp.com

Related documents:

• Security overview
• Extension Privacy & Permissions
• CLI Security & Privacy
• Privacy policy and GDPR details