DEV Community: Roberto Vázquez González

Verifiable Bookmarklets

Roberto Vázquez González — Mon, 27 Jul 2026 00:00:00 +0000

I just added a small new tool to the site: Verifiable Bookmarklets. Every bookmarklet it generates carries a SHA-256 fingerprint, so anyone can check that the javascript: link they received was really built from the source code they were shown.

It is a lightweight reproducible-builds mindset applied to bookmarklets. Nothing more than that.

The question it answers is:

Can this bookmarklet be proven to match this source code?

That is all. It does not make bookmarklets secure. It does not sandbox them. It does not replace browser extensions or browser stores. A verified bookmarklet can still be bad code, dangerous code or code you should not run. But at least you can know whether the bookmarklet you received is exactly the bookmarklet that was built from the source being shown.

Why bookmarklets?

Bookmarklets are old, simple and still useful. You drag a link to the bookmarks bar, click it later and the browser runs a small piece of JavaScript in the current page. No install flow, no store review, no account, no backend.

I still use them every day at work. These are real ones I have written over the years to make repetitive tasks easier, all of them from a pre-AI world, but the same principles apply:

🐙 GitHub PR Feedback Extractor v1.0.0

The newest one. Run it on a PR and it opens a dialog listing every comment grouped by author. I tick the ones I care about and it copies a Markdown extraction I can paste straight into an AI agent to iterate on and address.

A GitHub skill with access to the GitHub CLI could do the same, but when I already have the comments in front of me, clicking a bookmarklet is just faster.

🔗📋 Copy page link v1.0.3

Generates a Markdown link to the current page and copies it to the clipboard. If there is text selected it becomes the link text, otherwise it falls back to the page title.

📤 Full Site To Markdown Extractor v1.0.3

Extracts the content of a page as Markdown so I can feed it to an AI agent. I will expand on this one in a following post.

🕳 🧩 🦑 📋 Show / Hide the Content Extractor v1.0.9

Shows an input on the page where I can type a CSS selector. It highlights the matching elements and copies their content to the clipboard.

Most of my others are too specific to my daily work to be worth publishing. The point is the shape of the list: tiny, boring, single-purpose automations that pull an identifier out of a page, reformat something into Markdown, or save me four clicks in an internal tool. An extension would be overkill for every single one of them.

Notice the version numbers too. These things get edited, regenerated and re-dragged constantly, which is exactly where provenance starts to matter.

Sharing them never worked well

There is no standard way to share a bookmarklet. Drag one to your desktop and you get a .inetloc file on macOS, a .url file on Windows or a .desktop file on Linux. They all contain the javascript: URL, but they are not human-readable and they are not nice to share.

For years I generated bookmarklets with Bookmarklet Maker, which takes normal JavaScript and gives you back a bookmarklet ready to drag into the browser. That solved generation well enough that I never looked for anything else. I shared them with colleagues, they shared them with me, and I treated them as informal web scripts without any more pretension than that.

The part that changed recently

Because of LLMs, the generation step has become trivial. Ask for "a bookmarklet that does X" and you get working code back in seconds. That is genuinely useful and I do it often. It also means a lot more javascript: URLs are being generated, pasted into Slack and shared between people who never saw the source.

So more mates share bookmarklets with me, and I share more with them. Generation is no longer the bottleneck.

Which is when it hit me: how do I know that the bookmarklet I received is exactly the one that was built from the source I was shown? And how can I be sure the bookmarklet I am about to share is exactly the one built from the source I am showing?

Whether that source was written by me, by a colleague or by a model does not really change the question:

Is this bookmarklet exactly what this source produces?

Before

Share an opaque javascript: URL
Trust the author
Impossible to compare
"Looks fine"

After

Share a source URL
Verify the build
Deterministic SHA-256
"Matches source"

How it works

Each generated bookmarklet contains a small metadata comment:

/*bm:v1;sha=<sha256>;src=<optional-url>*/

The tool builds the payload, hashes it with SHA-256 and embeds that comment. The hash does not include the metadata itself, which avoids the circular problem of hashing something that contains its own hash.

The pipeline is deliberately short:

normalize source (normalize newlines, trim)
      ↓
build payload
      ↓
SHA-256(payload)
      ↓
embed metadata
      ↓
share

The tool can already:

generate a bookmarklet from pasted JavaScript source
generate a bookmarklet from a raw JavaScript URL
create a draggable bookmarklet link
inspect a pasted or dropped bookmarklet
show decoded JavaScript and metadata
verify a bookmarklet against the current source

Everything runs in the browser. No backend, no login, no publishing service.

It also generates a shareable link to the tool with the source URL as a parameter, so anyone can review the source and generate the bookmarklet themselves:

https://robertovg.com/projects/verifiable-bookmarklets/?src=<url-encoded-source>

Two workflows

That source URL parameter turned out to be the better way to share a bookmarklet.

Authoring. Publish the source, for example as a GitHub Gist, and link to Verifiable Bookmarklets with that URL as a parameter. The tool fetches the source, generates the bookmarklet locally and shows the fingerprint. Every reader reviews plain JavaScript and builds the executable in their own browser instead of trusting a long opaque link. Pinning a specific Gist revision rather than the mutable latest URL makes the reference stronger, because the source itself cannot change under you.

Verification. When someone shares the bookmarklet itself — "I found this in Slack, is it still the original?" — the embedded metadata is what helps. Inspect it, read the src and sha, fetch the source, regenerate and compare.

What verification means

Verification means:

This bookmarklet matches this source.

It does not mean:

this bookmarklet is safe
this bookmarklet is trustworthy
this source is the original source
this source URL will always return the same code

This is about provenance, not security. I think that distinction matters. Small tools become more useful when they make narrow claims and keep those claims honest.

The three functions that carry the idea

Generating the payload and the fingerprint createPayload, createMetadata and verify

function normalizeSource(source) {
  return source.replace(/\r\n?/g, '\n').trim()
}

function minifySource(source) {
  return normalizeSource(source)
}

function encodeBookmarkletValue(value) {
  return encodeURIComponent(value)
    .replace(/'/g, '%27')
    .replace(/"/g, '%22')
}

function encodeBookmarkletBody(body) {
  return `javascript:${encodeURIComponent(body)}`
}

function createPayload(source) {
  return encodeBookmarkletBody(`(()=>{${minifySource(source)}})()`)
}

function createMetadata(sha, src) {
  return src ? `/*bm:v1;sha=${sha};src=${encodeBookmarkletValue(src)}*/` : `/*bm:v1;sha=${sha}*/`
}

And verifying, which rebuilds the payload from the decoded bookmarklet, hashes it and compares it against the embedded sha. It never executes the code:

async function verify(bookmarklet, source) {
  const { decoded, hasScheme } = decodeBookmarklet(bookmarklet)
  const { metadata } = parseMetadata(decoded)
  const payloadBody = removeMetadata(decoded)
  const payload = hasScheme ? encodeBookmarkletBody(payloadBody) : payloadBody

  return metadata.sha === (await sha256(createPayload(source)))
}

The deterministic step stays conservative on purpose: normalize newlines, trim the source, hash the generated payload. It just turns JavaScript you could run in your console into a bookmarklet you can check.

The rest of the implementation lives in this site's GitHub repo.

Try it

Open Verifiable Bookmarklets.

Instead of sending someone an opaque javascript: URL, I can now send them a link to the source and let them generate the executable themselves, like this 📤 Full Site To Markdown Extractor.

AI made generating bookmarklets trivial. I wanted to simplify the sharing process and give some transparency to the provenance of the code. This tool does that, and I hope it is useful to others too.

My /uses page, six years later

Roberto Vázquez González — Wed, 15 Jul 2026 00:00:00 +0000

I just updated my /uses page for the first time since... well, since a version of me that wrote JavaScript without types, deployed with create-react-app, and had never talked to an AI in a terminal.

Instead of quietly rewriting it and pretending nothing happened, I turned the page into a small timeline: what I use now on top, and the old version preserved below as historical data. I like these pages more when they're honest about time passing.

What actually changed

Looking at the diff between 2019-me and 2026-me, a few things stand out:

TypeScript won. I don't write plain JavaScript anymore, anywhere. TS on the frontend, TS on the backend with Nest.js. Python and Go joined the toolbox too, and Java quietly became an old friend I never call.

The tooling turned over almost completely. Alfred became Raycast. My terminal became Warp. create-react-app became Vite. Gatsby and Next.js are still around in projects I maintain, but Astro is where my new sites go. And most of my new projects now live on Cloudflare (Pages, Workers, KV) instead of scattered across half the internet.

AI agents are the biggest change by far. In 2019, "Editors" was a section about VSCode plugins. Now it's "Editors / AI Agents", because Claude Code, Codex, Copilot and friends are part of my daily workflow, both at work and on side projects. I still care about the same thing I cared about six years ago, though: the best tools are the ones that make life easier without the effort behind them being visible. That hasn't changed, only the tools have.

The hardware section got simpler. Same setup at home and at Corker (the coworking space I co-founded): MacBook Pro 16" behind an external monitor, external keyboard and mouse, so moving between the two feels like nothing. The AKG K240 + Aune DAC combo from the old list is still going strong. Some things are worth keeping.

What all of this is for

A /uses page can look like a list of shiny things, but for me it's the workshop, not the work. Most of this stack is currently pointed at being productive. AI is here to stay, and I genuinely like how it simplifies code creation, both at work and outside of it. But I also like to keep creating things from scratch, no AI assistance, just to keep my coding brain sharp and in good shape, up to date with how things actually work under the hood.

If something on the list catches your eye and you want to know more, reach out. And if you have a /uses page of your own, I'd genuinely love to see the diff between your past and present self.

Rebooting this website

Roberto Vázquez González — Sun, 05 Jul 2026 00:00:00 +0000

It's been a while.

The last article I published here was back in 2020, when I wrote about my /uses page. Looking back, it's hard to believe how much has changed since then, both in my life and in the tools I use every day. Updating that page is definitely overdue, but I'll save that for another day.

The world went through the COVID-19 pandemic and lockdowns, life moved on, and over the years this website slowly stopped being a priority.

Not because I stopped building things, quite the opposite.

Since then, I've been working at EverQuote, where I've had the opportunity to work on products at a much larger scale than ever before. I also married my life partner, Nuria, and not long afterwards our family started to grow. First came Berta, and two years later Elio, by far the biggest and best change in our lives.

Like many people, I simply had different priorities.

Simplifying things

One thing I did want to improve was where all my personal projects live.

Over the years I ended up hosting different sites across AWS, Vercel, Netlify, Google Cloud and a few other places. It was fun, and a great excuse to learn and compare different platforms, but it also meant jumping between providers every time I wanted to touch one of my projects.

Lately I've been moving everything to Cloudflare.

For my personal projects, it hits a really nice balance between simplicity, performance and cost. Having hosting, deployments and domain management in the same place makes maintaining everything much easier.

Migrating everything there also gave me the perfect excuse to revisit this website, refresh the content and make it better reflect who I am today.

Looking forward

This isn't a "big relaunch". Just a small reboot.

I have a personal project I'm very excited about and that I hope to start shipping soon.

Its name is SongForm.

My hope is that this website becomes a place where I occasionally document that journey, share things I learn along the way, and publish the odd article when I have something worth sharing.

Why keep writing?

I did wonder whether maintaining a personal website still made sense in a world increasingly filled with AI-generated content, or what better said "AI slop."

The more I thought about it, the more I realised that's exactly why it does.

I use AI every day, both personally and professionally. I think it's one of the most useful TOOLS I've ever had. It helps me build faster, execute ideas more efficiently, research unfamiliar topics and augment my knowledge.

That said, I've found it's most valuable when I already understand the subject well enough to review its output critically, separate facts from hallucinations and apply my own experience.

Personal websites were never about producing as much content as possible. They're about documenting a journey, sharing lessons learned and occasionally building something that someone else might find useful.

AI can help me write. It can help me code. But it can't accumulate my experiences for me.

So here's to rebooting this little corner of the internet.

Hopefully this is the start of writing here a little more often.