webchanges vs urlwatch: a comparison

The 4 high-value wins

If any of these match what you actually monitor, urlwatch can't keep up. Each is a webchanges feature with no native urlwatch equivalent.

url: https://hard-to-scrape.example/
http_client: curl_cffi
impersonate: chrome
http_version: v2tls

differ:
  name: ai_google
  prompt: 'Summarize material changes by section.\n\n{unified_diff}'

url: https://example.com/logo.png
differ:
  name: image
  data_type: url
  mse_threshold: 5.0

differ:
  name: deepdiff
  data_type: json
  ignore_order: true
  significant_digits: 2

Use webchanges if…

• Any of the four wins above apply.
• You need granular Playwright control: block_elements, evaluate, chained wait_for_*, persistent user_data_dir, switches, http_credentials.
• You want reporters that earn their keep: github_issue turns each change into a tracked ticket with labels/assignees/milestones; mailgun for transactional email; browser opens the HTML report locally; run_command exposes {count}/{jobs}/{text} plus WEBCHANGES_*_JSON env vars.
• You want Telegram with formatting: bold/italics/strikethrough/links via Markdown, not plain text plus a monospace flag.
• You want snapshot retention controls: max_snapshots caps storage growth and --rollback-database recovers from a bad filter change. urlwatch keeps every snapshot.
• You want safer external commands: the execute filter runs a program without shell interpretation. shellpipe is still available but flagged as a security risk.
• You want extra filters at the edges: ascii85, base64, format-xml, jsontoyaml, pypdf, remove_repeated, absolute_links; renamed keep_lines_containing / delete_lines_containing with text+re modes.
• You want a JSON Schema (config.schema.json) for editor autocomplete.
• You need HTTP/2 to access sites.

Migration is mostly drop-in: jobs.yaml / config.yaml are largely compatible, and the database auto-migrates. Original files are retained so you can go back if you want.

Full reference comparison

Source: each project's official reference docs.

Jobs & universal directives

HTTP client & fingerprinting

Browser jobs (Playwright)

Both projects use Playwright and support the same engines (chromium, chrome, firefox, webkit, msedge). The difference is the directive surface, which is much broader for webchanges.

Filters

Both share the core (CSS/XPath, html2text, jq, pdf2text, OCR, regex, sort/reverse). Differences is the additional filters offered by webchanges.

• webchanges-only: execute (safer than shellpipe), ascii85, base64, between, format-xml, jsontoyaml, pypdf, remove_repeated, absolute_links, enhanced strip (chars/side/splitlines), format-json with sort_keys, pdf2text with raw/physical.
• Renamed in webchanges: grep → keep_lines_containing, grepi → delete_lines_containing (both accept text or re in webchanges).

Differs

Reporters

Command-line interface

Webchanges adds operational tooling for testing, retention, recovery, observability, and packaging.

Configuration & database

• webchanges exposes differ_defaults (per-differ defaults), database (engine + max_snapshots), global tz, and footnote. Ships config.schema.json for editor autocompletion. Underscore-prefixed keys (_note:) act as inline comments.
• Database backends — webchanges allows to set max_snapshots to define retention.
• Default config locations — webchanges: Linux ~/.config/webchanges, macOS ~/Library/Preferences/webchanges, Windows %USERPROFILE%\Documents\webchanges.

FAQ

Sources (reference docs)

• webchanges — Jobs & directives
• webchanges — Filters
• webchanges — Differs
• webchanges — Reporters
• webchanges — Configuration
• urlwatch — Jobs
• urlwatch — Filters
• urlwatch — Reporters
• urlwatch — Configuration