DEV Community: Jerome Leto

Previewing and installing desktop pets in the Codex app

Jerome Leto — Thu, 10 Sep 2026 06:59:35 +0000

A desktop pet is a small customization, but choosing one is surprisingly visual. A character that looks great as a still image can feel distracting when it loops beside your work. I maintain Best Codex Pets, a small gallery for browsing animated companions for the Codex desktop app before downloading a package.

This is an unofficial resource. It is not an OpenAI product, and the pets are desktop companions rather than a feature added to every terminal that runs the Codex CLI.

Start with the animation

The gallery has Featured, Popular, and Newest views. Each pet has a detail page with a browser preview and a ZIP download. The practical advantage is that you can look at the character in motion before putting files into your local pets directory.

Five current examples are CorgiByte, Mint Fox, Inkbyte, Ember Loop, and Glint. They range from a recognizable corgi silhouette to simpler fox, ink-drop, ember, and spark designs. I would start by comparing a detailed character with a minimal one: how much motion do you actually want beside a coding session?

The gallery is deliberately small. It is useful as a place to choose a companion, not as a claim that every available Codex pet has been collected or independently reviewed.

Install the package in the right place

The site's installation guide describes this workflow:

Open a pet's detail page and download its ZIP.
Inspect the archive before extracting it. A pet package should contain its manifest and spritesheet.
Place the pet's folder under ~/.codex/pets/.
In the Codex desktop app, select the pet under Settings → Appearance → Pets, then use /pet to show it.

A typical directory looks like this:

~/.codex/pets/
└── chosen-pet/
    ├── pet.json
    └── spritesheet.webp

Keep each companion in its own folder. If an archive adds an extra enclosing directory, check where the two files actually landed. Avoid overwriting a companion you already customized. If the appearance settings differ in your app version, check the app's current instructions before changing unrelated configuration.

Keep the asset license separate

A gallery being free to browse does not mean every image has the same license. The current catalog lists CorgiByte as MIT and several other entries as all-rights-reserved. Check the specific pet's attribution and terms before reusing artwork in another project or redistributing a modified package.

For everyday use, the workflow is simple: preview a few animations, choose one, inspect the package, and follow the installation steps. There is no need to run an unfamiliar shell installer just to browse a character.

You can browse the gallery or inspect the public project README. Feedback on confusing installation steps or preview behavior is welcome; those are more useful improvements than adding a long list of pets that are hard to tell apart.

3 months of an image-to-Base64 tool site: pure frontend, Worker + D1, and the 33% size overhead tradeoff

Jerome Leto — Sat, 05 Sep 2026 06:08:50 +0000

I wanted a dead-simple image-to-Base64 converter: no uploads, no signup, no popup ads. Couldn't find one I liked, so I built one.

How it works

100% client-side: FileReader -> data URI. The image never leaves the browser.
Production stack: Cloudflare Worker serving static assets + a D1 database for cookieless anonymous event counts (no image data, no personal info -- only event name, page path, mime type and size bucket).
The tool shows the exact encoding overhead for each file instead of a flat estimate.

Two tradeoffs I made

Base64 inflates payload size by ~33% (3 bytes become 4 chars). The page displays the encoded size up front instead of pretending it's free.
No AdSense yet. Traffic is tiny; I'd rather protect the UX while finding the first 100 real users.

The honest numbers (3 months)

Google Search Console: 224 clicks / 3,249 impressions
The embarrassing part: every single click comes from branded queries (people searching the domain). Non-branded organic search: 0
The only external links Google recognizes so far: 4 links from dev.to

Tool-site founders: how do you get organic search from 0 to 1? Backlinks, content pages, directories -- what actually worked for you?

Site, feedback welcome: image2base64.com

When (and when not) to inline images as Base64

Jerome Leto — Fri, 03 Jul 2026 03:39:02 +0000

Base64 image data URIs are one of those web techniques that look like a magic shortcut the first time you use them.

Instead of referencing an external file:

<img src="/logo.png" alt="Logo">

you can put the image bytes directly in the document as text:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." alt="Logo">

That can be useful. It can also make a page slower, harder to cache, and more annoying to maintain.

Here is the practical rule: inline images as Base64 when self-containment matters more than caching. Keep normal image files when the browser should be able to cache, resize, lazy-load, or optimize them independently.

What a Base64 image actually is

An image file is binary data. Base64 rewrites that binary data as plain text using a limited character set. To make the browser treat the text as an image, you wrap it in a data URI:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...

The first part tells the browser the MIME type. The second part tells it the data is Base64 encoded. The long tail is the image itself.

Base64 is not compression. It is not encryption. It is just a text representation of the same bytes.

When inlining an image is worth it

1. Tiny icons and UI assets

For very small images, removing an extra HTTP request can be worth the extra bytes. This is especially true for small icons, logos, placeholders, simple UI sprites, or tiny transparent PNGs.

Modern HTTP/2 and HTTP/3 make extra requests cheaper than they used to be, so this is not an automatic win. But for a one-off tiny asset inside a small page or widget, a data URI can still be a clean choice.

2. Single-file deliverables

Sometimes the point is not raw page speed. Sometimes you need one file that carries everything with it:

an HTML report
an email template
a CodePen or demo snippet
a CMS block where you cannot upload assets
a test fixture that should not depend on external hosting

In those cases, Base64 is useful because the image travels with the HTML, CSS, JSON, or JavaScript.

3. Prototypes and throwaway snippets

If you are testing a layout, writing a bug reproduction, or pasting a minimal example into a ticket, a data URI can save time. You do not need to set up static hosting just to show one image.

4. Local-only conversion workflows

If the image is private, it is nice to avoid uploading it to a random converter. Browser APIs can generate a Base64 data URI locally, so the file never leaves your device.

When you should not inline the image

1. Large photos and hero images

Base64 usually makes the encoded data about 33% larger than the original binary file. That is because Base64 stores every 3 bytes as 4 text characters.

For a large JPG, PNG, or WebP, that extra size is not a rounding error. Keep big images as normal files.

2. Images reused across pages

An external image can be cached once and reused across page views. An inlined image is bundled into every document or stylesheet that contains it.

If the same logo appears on 20 pages, inlining it 20 times is usually worse than letting the browser cache one file.

3. Responsive images

Normal image files can use srcset, sizes, lazy loading, CDN transforms, format negotiation, and caching headers.

<img
  src="/hero-800.webp"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1600.webp 1600w"
  sizes="100vw"
  loading="lazy"
  alt="Product screenshot"
>

That is much harder to preserve when the image is baked into a string.

4. Anything you expect humans to edit

Base64 strings are unpleasant to review in Git diffs, easy to truncate by accident, and noisy inside templates. If designers, marketers, or other engineers need to update the image regularly, use a normal asset file.

How to generate a Base64 data URI in the browser

The simplest browser-native path is FileReader.readAsDataURL().

<input id="file" type="file" accept="image/*">
<textarea id="output" readonly></textarea>

<script>
  const fileInput = document.querySelector("#file");
  const output = document.querySelector("#output");

  fileInput.addEventListener("change", () => {
    const file = fileInput.files[0];
    if (!file) return;

    const reader = new FileReader();
    reader.onload = () => {
      output.value = reader.result;
    };
    reader.readAsDataURL(file);
  });
</script>

The result will look like this:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...

You can use that string directly in HTML:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." alt="Logo">

or in CSS:

.logo {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...");
}

A simple checklist

Inline the image if:

it is small
it is not reused across many pages
self-contained delivery matters
you do not need responsive image behavior
the string will not make your source files painful to maintain

Keep it as a normal file if:

it is a photo or large graphic
it should be cached separately
it appears on many pages
it needs srcset, lazy loading, CDN resizing, or image optimization
non-developers need to replace it often

Tiny tool note

I built a small free tool for this workflow: PNG to Base64 converter. It runs entirely in the browser with FileReader, so the PNG is not uploaded, and it gives you the raw Base64 string plus ready-to-paste HTML and CSS snippets.

There is also a general image to Base64 converter for JPG, SVG, WebP, GIF, and other image formats.

Use Base64 as a packaging tool, not a default image strategy. When the image is tiny or the deliverable must be self-contained, it can be perfect. When performance, caching, and responsive delivery matter, boring old image files are still the better answer.