I have a confession: as a developer who drinks too much black tea and too little sleep, I get emotionally invested in software drama. So when I learned that Google bought a tiny video-compression company called On2 Technologies and then — in the blink of an engineer’s eye — used its tech to birth whole new media formats, I felt proud and betrayed in equal measure. Proud because a small piece of internet plumbing got shared with the world. Betrayed because the same company that gave us the idea for WebP sometimes treats that idea like a shy cousin at the family reunion — “Yes, we invented it. No, you can’t sit with us in Docs.”

Let me paint the timeline for you like I’m telling a friend over nyama choma: Google announced the purchase of On2 (the deal value was reported in that $100–$130M ballpark) and then set free a video codec called VP8, which quickly became part of the WebM family of open media tech.

From that lineage came WebP — Google’s image format (announced in 2010) that promises smaller files for the same quality (or better) because it borrows tricks from VP8. WebP was explicitly described as “based on technology acquired when Google bought On2.” In other words: On2 → VP8 → WebM & WebP. That’s not arcane corporate pedigree — it’s literal family tree business.

So far, so heroic: a company buys a clever codec, liberates the tech, and gifts the web something that can reduce page weight and improve speed. As a dev, I love that story. As a human who stores memes and portfolio images inside Google Docs like everyone else, I also raise an eyebrow when the inventor’s own apps act like they don’t speak the same language.

The bit that smells like hypocrisy (and makes me grin in disbelief)

Here’s the thing: Google created or enabled WebP, promoted it on developer pages, and Chrome happily displays it. Yet, when people try to insert .webp images into Google’s productivity apps — Docs, Slides, or Sheets — they run into errors like “unsupported image type” or find they can’t import certain .webp files at all. Users keep reporting this pain in Google product forums and help threads. It’s as if the big company that evangelized WebP forgot to invite it to the party when they put the chairs around the Docs table.

I can’t help but picture a small startup that taught everyone how to make jollof rice properly, only to be told later, “nice recipe — but we’ll only use rice in our restaurants if it’s white rice.” It’s deliciously ironic.

Now, before the Google defenders sharpen their Twitter replies: yes, WebP is widely supported in browsers and many web tools (Chrome, other engines, many dev libraries). The tech is solid and Google’s own dev docs sing WebP’s praises. But real-world support in document editors — the place where people paste images from the web into meeting notes, shared slides, or spreadsheets — has been inconsistent enough that users keep having to convert files or use workarounds. That’s the part that feels off.

Why this actually matters (and why it’s more than petty grumbling)

If you’re a builder (or a content manager or a startup founder or, yes, a developer from Nairobi who is trying to squeeze bytes out of a slow connection), every kilobyte saved matters. WebP often shrinks images compared to JPEG or PNG, which improves page load, bandwidth bills, and user experience — especially on mobile data caps and slow connections (shout-out to anyone who’s lived with Safaricom’s “welcome to lower speeds” surprise). When a company that pushed WebP doesn’t make it easy to use within its own productivity suite, it’s not just irony — it’s friction that affects real people and workflows.

Also: imagine building an internal process that exports thousands of images as WebP (because someone in marketing followed the performance playbook), then being told by the documentation team that Google Slides won’t import them. That’s operational friction. It’s the kind of mismatch that makes dev teams say: “Fine — we’ll convert everything back to PNG. Again.” That conversion step is time, cognitive overhead, and potential quality loss. It’s tiny per-image, but enormous at scale.

So what’s going on under the hood? (short, not boring, promise)

I suspect this is less about ideological hypocrisy and more about engineering choices, backwards compatibility, and product priorities. Editors like Docs and Slides are complex beasts — they render collaborative layers, annotations, embedded objects, and a sweaty tangle of MIME types. Adding or hardening new image format support means thinking about color profiles, transparency modes, metadata, animation frames, and editor-side rendering. WebP has been extended (lossy, lossless, animation, alpha), and not all decoding paths are equal. Google’s browser team (Chrome) and Google’s productivity-apps team are different tribes with different priorities and release schedules. But you know what? That technical explanation doesn’t make for a better user experience. It just explains why the hypocrisy looks like bureaucracy. The users don’t care about org charts.

If you want the receipts: Google’s own WebP pages and dev docs show that WebP is a format they actively maintain, and browser support is broad. Yet product help threads and community posts repeatedly mention the inability to insert WebP into the Docs family without conversion. That contrast is the whole point.

My tiny, slightly audacious project idea: WebP Bridge (let’s fix the mismatch)

Okay, rather than just laugh and post a meme about it, I propose we build something useful — a small open-source tool that un-gums the wheels for people who actually need to use WebP with Google Docs / Slides / Sheets. I call it WebP Bridge (name up for debate; Kenyan street-side branding not included).

What WebP Bridge does (MVP)

• Lets you drag/drop a .webp into Docs/Slides/Sheets and either:

  • Convert it client-side to a supported inline format (PNG/JPEG) while preserving quality and transparency, or

  • Upload the .webp to Drive and insert a Drive-hosted preview that renders correctly in the editor.

• Option A: a Chrome extension (Manifest V3) that intercepts drag-and-drop and does fast WASM-based conversion using libwebp compiled to WebAssembly — so no server, no upload, privacy-friendly.

• Option B: a Google Workspace Add-on / Apps Script helper that converts .webp files in Drive to editor-friendly formats (batch convert, on-upload hook).

• UX: one-click convert, choose target format + quality, optionally keep original in a “/webp-originals” Drive folder.

Why it’s realistic

• libwebp already exists and can be compiled to WASM; client-side conversions are fast on modern machines.

• Chrome extension can do the conversion without server cost or privacy leakage.

• Google Apps Script can mediate Drive conversions for folks who prefer server-side batch jobs.

• This solves the pain immediately for end users and gives us an open-source demonstration to share with Google product teams — the kind of PR that says: “Hey, this matters to people.”

Tech stack (lean and mean)

• Frontend: TypeScript + simple React UI for extension popup / settings.

• WASM: libwebp compiled to WebAssembly (for fast in-browser encode/decode).

• Extension: Chrome Manifest V3 (works in Chromium-based browsers).

• Optional Backend: Cloud Function (Node.js) for heavy batch conversions (if needed).

• Workspace Add-on: Google Apps Script for Drive automation and menu integration.

30/60/90 plan (MVP timeline)

• 0–7 days: Repo, README, minimal extension skeleton, compile libwebp to WASM, demo decode/encode in-page.

• 8–21 days: Drag/drop interception + convert & insert PNG blob into HTML5 canvas; test in local Google Docs page.

• 22–45 days: Polish UX, add options (quality, alpha handling), build Apps Script Drive converter.

• 46–90 days: Publish on Chrome Web Store + GitHub, documentation, and a small blog post showing the problem → the fix (that’s me — hello, content loop).

Why this matters for the Web & for me (and you)

• It’s practical: saves folks time and bandwidth.

• It’s political, in the healthy sense: it forces product teams to notice. When people adopt the extension and the community upvotes the idea, Google’s product managers can’t pretend the problem is invisible.

• It’s a vehicle for visibility: we can make the repo public, write the blog, demo in a Twitter Space, and maybe get noticed by the very engineers who originally worked on WebP. As a developer from Nairobi, this is the kind of modest, high-signal project that gets you interviews, invites, and maybe even a grant.

Final note as developer’s final jest

I’m not saying Google is evil. Big companies are full of brilliant people and their products change the world. But when the same corporation that pushed a file format makes it awkward to use that format inside their own everyday apps, it’s funny in the way a matatu driver ignoring traffic rules is funny: it’s only funny until someone loses a meeting slide.

So, I’ll roll up my sleeves. I’ll build WebP Bridge. If it helps even one person in a small Nairobi co-working space stop converting 200 images to PNG every week, it’ll be worth it. And if it nudges Google to open the doors a bit wider in Docs/Slides/Sheets, then the hypocrisy gets replaced by usefulness — and the internet gets one less annoying friction point.

If you’re curious or want to build with me: get a WASM compiler, a coffee (or black tea), and let’s make a tiny open-source bridge that even Google’s editors can’t ignore.