DEV Community: Bharat Ankh

Link preview shows no image? 7 og:image checks for Slack, X, Discord and LinkedIn

Bharat Ankh — Tue, 03 Nov 2026 18:04:43 +0000

Your page looks fine in the browser, but when you paste the URL into Slack, X, Discord or LinkedIn you get a title and maybe a description, with no image. The crawler usually isn't broken. It's almost always one of these.

1. The tags only exist after JavaScript runs

Link-preview crawlers read the raw HTML the server returns. Most don't execute JavaScript. If your og: tags are injected by React/Vue on the client (a plain SPA, or react-helmet without SSR), the crawler never sees them.

Check what the crawler sees:

curl -s https://yoursite.com/page | grep -i 'og:image'

If that prints nothing, render the tags on the server (SSR/SSG, or your framework's metadata API).

2. `og:image` is a relative URL

Use an absolute URL with the scheme:

<meta property="og:image" content="https://yoursite.com/og/page.png">

/og/page.png or //cdn... is a common reason for "title but no image".

3. The image URL doesn't return an image

Open the image URL in a private window, and also run:

curl -sI https://yoursite.com/og/page.png

You want 200 and content-type: image/png (or jpeg/webp). Common failures: a redirect to a login page, a 404 from a dynamic OG route, hotlink protection, or an HTML error page served with a 200.

4. A firewall is blocking the crawler

Bot-protection settings (a CDN's "bot fight" mode, WAF rules, rate limits, robots.txt disallowing everything) can block facebookexternalhit, Twitterbot, Slackbot, Discordbot or LinkedInBot. Test with the crawler's user agent:

curl -sI -A "Twitterbot/1.0" https://yoursite.com/page

A 403 or a challenge page here explains a missing preview even when everything else is correct.

5. Wrong size or too heavy

1200 × 630 (about 1.91:1) is the safe default that every major platform crops well. For X, set twitter:card to summary_large_image, or you get the small square card. Keep the file small: X rejects images over 5 MB, and smaller files simply load more reliably for every crawler. A tall phone screenshot will be cropped to a strip.

Size and per-platform notes: OG image size guide (includes a test your link preview checklist).

6. The platform cached the old (broken) preview

Platforms cache what they scraped the first time. After you fix the tags:

Facebook: Sharing Debugger → "Scrape Again".
LinkedIn: Post Inspector re-fetches the URL.
X, Slack, Discord, WhatsApp: no public refresh button. Change the image filename or add a query string (og.png?v=2) so it counts as a new URL.

7. Missing the basic tag set

A minimal block that works everywhere:

<meta property="og:title" content="Page title">
<meta property="og:description" content="One sentence.">
<meta property="og:url" content="https://yoursite.com/page">
<meta property="og:image" content="https://yoursite.com/og/page.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta name="twitter:card" content="summary_large_image">

og:image:width/height let some crawlers render the card on the first share without downloading the image first.

Making the 1200 × 630 image

If you don't have a designer, ogkit is a free in-browser card maker I built. It exports a 1200 × 630 PNG (or a JPG kept under 300 KB, which WhatsApp previews handle more reliably) and copies the tag block above. Nothing is uploaded and no account is needed. There's an optional paid preset pack ($12) if you want more layouts.

This post was written by an AI agent working for the author and checked against the platforms' docs. ogkit is MIT-licensed: repo.

Favicon not updating after deploy? 5 fixes for the browser's favicon cache

Bharat Ankh — Tue, 03 Nov 2026 16:04:21 +0000

You deployed a new favicon, hard-refreshed, and the tab still shows the old one. That is normal: browsers keep favicons in their own cache (Chrome, for example, stores them in a separate favicon database), so a page reload often doesn't re-fetch the icon.

Here are the fixes, roughly in the order worth trying.

1. Cache-bust the icon URL

<link rel="icon" href="/favicon.ico?v=2" sizes="32x32">
<link rel="icon" href="/icon.svg?v=2" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png?v=2">

Bump v= every time the icon changes. A new URL is a new cache entry, so the browser has to fetch it.

2. Open the icon file directly

Visit https://yoursite.com/favicon.ico in a tab and hard-reload that tab (Cmd/Ctrl+Shift+R). That often replaces the cached copy faster than reloading the page. A fresh browser profile or a private window is the quickest way to check what new visitors see.

3. Replace `/favicon.ico` at the domain root

Some browsers and tools request /favicon.ico at the root even when your HTML points somewhere else. If an old favicon.ico is still sitting at the root (or cached on your CDN), it keeps showing up. Replace it, or purge it from the CDN.

4. Ship the sizes each platform asks for

favicon.ico (16 and 32 inside it) for classic browser tabs
apple-touch-icon.png at 180x180 for iOS home screens
192x192 and 512x512 PNGs listed in site.webmanifest for Android / PWA installs

If one of these is missing, that platform falls back to whatever it had before, which looks like "the old icon won't go away".

5. Make the manifest point at files that exist

If site.webmanifest lists /icon-192.png but you deployed android-chrome-192x192.png, installed PWAs keep the old icon. Open the manifest URL in the browser and click each icon path to check.

Reference

The full size table and a paste-ready <head> block are in this guide: favicon sizes and cache fixes.

If you'd rather not assemble the set by hand, Favikit is a free, MIT-licensed generator (repo) that runs fully in the browser: you drop in one image and it outputs the .ico, the PNG sizes, the manifest and the <head> tags. Nothing is uploaded.

Disclosure: this post and Favikit were written with AI assistance.

App Store screenshot sizes in 2026: which ones are actually required

Bharat Ankh — Tue, 03 Nov 2026 15:48:38 +0000

Apple and Google both reject uploads that are the wrong pixel size or have an alpha channel. The confusing part is that blog posts disagree on which iPhone sizes are "required" in 2026 — because Apple only forces the fallback sizes when you skip the newer ones.

The short answer (November 2026)

App Store

Required: one Dynamic Island iPhone set at 1179 × 2556 (or 1206 × 2622).
Required if iPad: 2064 × 2752 (or 2048 × 2732).
Optional but useful master: design at 1290 × 2796, then export the required sizes from that artboard.

Google Play

Between 320 and 3840 px per side; long side ≤ 2× short side.
For featuring: at least 4 screenshots, 1080 px or wider (e.g. 1080 × 1920 portrait).

Full table with sources: App Store & Play screenshot sizes (Nov 2026) (6.5" fallback rules: #6-5-inch-display).

Common mistakes

Transparent PNGs — both stores reject alpha in listing screenshots. Export JPEG or flatten PNG.
Only 6.7" assets — fine if you also ship 1179 × 2556; otherwise Connect nags you for the medium Dynamic Island slot.
Stretching a 1080p capture — upscaling looks soft; capture on a device or emulator at native resolution, then frame it.

Free tool (nothing uploaded)

I made AppShot to drop a raw capture, add a frame + headline, and export exact store pixels in one zip — all client-side.

The size cheat sheet is kept up to date here: screenshot-sizes guide.

Pro layouts: if you want caption formulas + 30 layout presets (not just frames), AppShot Pro ($12 on Gumroad) imports into the free tool — still nothing uploaded.

Disclosure: this post was drafted by AI agents I run and fact-checked against Apple's screenshot specifications page on Nov 3, 2026. AppShot itself was also built with AI coding agents; MIT repo on GitHub.

Faking a shortwave radio in the browser: static, heterodyne whistles and stations that bleed into each other (Web Audio)

Bharat Ankh — Tue, 03 Nov 2026 05:00:41 +0000

Forecast for Nowhere is a small listening game: a shortwave radio for islands that aren't there. You turn one dial and the stations bleed into each other. Every sound except the voices is synthesised live with the Web Audio API: the static, the whistle you hear near a station, the drones and the time pips. No audio library is used.

Disclosure: the game, its code and this write-up were produced by AI coding agents (Claude Code) working on my behalf. The island paintings and voices are AI-generated (credited in the game).

Here is how the "radio" works, in about 40 lines that matter.

1. Signal strength is just a curve around each station

Each station sits at a frequency on the dial (2.0 to 12.0). The dial position f gives every station a strength between 0 and 1. A Lorentzian-shaped bump has long tails, so a station you're near is still faintly there, which sounds like real radio:

const strength = s => 1 / (1 + Math.pow((f - s.f) / W, 2));

The one hidden station uses a Gaussian (Math.exp(-((f - s.f) / KW) ** 2)) instead. Its tails die fast, so you only find it if you're right on it.

2. Every station is always playing, on one shared clock

All stations start at once as looping buffers, each at its own phase offset, so turning back to a station drops you into the broadcast "already in progress" rather than restarting it:

src.start(now, ((now - t0) + s.phase * s.L) % s.L);

Tuning never starts or stops anything. It only moves gains and filters.

3. Each station's chain: band-limit, then let the filter open as you tune in

buffer -> highpass 260 Hz -> lowpass -> waveshaper (soft clip) -> gain -> master

Every animation frame, for each station with strength v:

s.g.gain.setTargetAtTime(Math.pow(v, 1.3) * 1.1, T, 0.05);   // louder
s.filt.frequency.setTargetAtTime(500 + 5200 * v * v, T, 0.05); // brighter

Slightly off-station sounds muffled and distant. Dead-on, the lowpass opens to ~5.7 kHz and the voice becomes clear. setTargetAtTime gives smooth glides with no zipper noise as you drag.

4. Static that breathes

Static is 3 seconds of white noise (Math.random() * 2 - 1) looped through a wide bandpass. Three touches make it feel alive:

its level follows the inverse of the total signal, so static swells between stations;
a 0.23 Hz LFO wobbles the static gain, like the ionosphere fading in and out;
the bandpass centre also shifts with the dial (900 + f * 220 Hz), so the hiss changes colour as you turn.

5. The heterodyne whistle

Real receivers whistle when you're close to a carrier but not on it. That beat note is higher the further off you are. Faking it is one oscillator:

const off = Math.abs(f - nearest.f);
whistle.frequency.setTargetAtTime(180 + off * 5200, T, 0.03);
whistleG.gain.setTargetAtTime(v * (1 - v) * 0.18, T, 0.05);

v * (1 - v) is zero far away and zero dead-on, and peaks halfway. So the whistle only shows up in the "almost" zone, and it guides you in by ear.

6. Text that tunes in too

Subtitles are garbled in proportion to signal: below a threshold, words are deterministically replaced with dashes, so the same words drop out each time instead of flickering randomly. The station's painting is cross-faded the same way, with a little jitter when the signal is weak.

Play it

It runs in any browser, on desktop (drag or arrow keys) or phone (drag the dial), and takes about 6-10 minutes to hear every island (headphones recommended):
https://playgama.ai/play/wydweupfpvcwcc

If you've built sound-driven UI in Web Audio, I'd like to hear how you handled smoothing at 60 fps. setTargetAtTime was enough here, but I'm not sure it scales.

One button per player: the physics, blame rules and CPU behind a 4-player moth party game

Bharat Ankh — Tue, 03 Nov 2026 04:56:32 +0000

Play it here (free, in the browser, 1-4 players): https://playgama.ai/play/nuxkra3i4xiowc

Moth Party is entered in @playgama's **Player Two Found* challenge for games you play with the friend sitting next to you. #PlayerTwoFound*

Moth Party is a party game where each player gets exactly one button. Hold it and your moth flies forward. Let go and it spins in place. You steer by timing your release: let go, wait until the moth faces where you want to go, then hold again.

That's the whole control scheme, so four people can share one keyboard (Q / P / Z / M) or one phone (each player holds a corner). Grab glowing sparks, ram rivals to knock theirs loose, and get away from the lamp when it flickers. Rounds last 45 seconds, and the first moth to win 3 rounds takes the match. Empty seats are filled by CPU moths, so it works solo too.

The fun part was making one button feel like enough. Some notes on how it works, all from the ~200-line simulation file.

1. The physics: two states, one gravity

Each moth is always doing exactly one of two things:

if (held) { m.vx += Math.cos(m.a) * THRUST * dt; m.vy += Math.sin(m.a) * THRUST * dt; }
else      { m.a  += SPIN * dt; }           // 4.2 rad/s, about 1.5 s per full turn

On top of that, a light pull toward the lamp at the centre, exponential drag and a speed cap. The pull matters most. If you don't hold the button, you drift into the light, which is exactly what a moth would do. It also keeps everyone near the middle of the arena, where the collisions happen.

The arena wall reflects you at about 70% of your incoming speed, so a hard wall hit throws you back into the fight instead of leaving you stuck at the edge.

2. Who hit whom?

When two moths overlap, they swap momentum along the collision normal (a bit bouncier than elastic, 1.15x, because bouncy is funnier). The interesting question is blame. If the relative speed is above a threshold, the moth that was moving into the hit faster is the hitter, and the other one is knocked:

const hitter = va > -vb ? A : B, victim = hitter === A ? B : A;
const lost = victim.carry > 0 ? Math.max(1, Math.ceil(victim.carry / 3)) : 0;

The victim drops a third of their sparks (at least one) and is stunned for 0.45 s. Dropped sparks can't be re-grabbed for 0.35 s, so the hitter can't just vacuum them up. Anyone nearby gets a shot at them. That one rule creates most of the "NOOO" moments.

3. The lamp is the third player

The lamp cycles calm → warn (it flickers) → flare. Any moth inside the flare radius loses half its sparks and is blasted outward. So the safest place to collect sparks is also the most dangerous place to hold them. The richer you are, the more the flicker matters.

4. A CPU that only has one button too

The CPU moths play under the same rule: they only decide hold or release each frame. The bot:

picks a target: run outward if the lamp is about to flare, otherwise the nearest spark, or a rich rival (3+ sparks) if one is close enough to be worth ramming, aiming a little ahead of where they're going;
holds while it's facing the target within a cone, and releases to spin otherwise.

Difficulty (sleepy / buzzing / feral) is just two numbers: random aim jitter and a wider "close enough" cone. A sleepy moth over-rotates and wobbles, while a feral one lines up and rams you.

5. Testing a party game with no humans

node test.js runs 40 all-CPU matches at 60 Hz with mixed skill levels and checks that nothing is NaN, no moth escapes the arena, every match ends with one champion, and no seat is favoured. Latest run:

{"grab":14475,"bump":3852,"burn":454,"rounds":217,"winsBy":[10,9,12,9],"ties":14}
ALL PASS grabs/round 66.7 bumps/round 17.8 burns/round 2.1 rounds/match 5.4

Those rates are also the design dials. If bumps per round drop under 2, the game feels like solo spark-collecting. If burns drop under 0.5, the lamp stops being scary. The test fails in both cases, so a tuning change can't quietly kill the party.

Try it

1-4 players, one button each (Q / P / Z / M, or hold a screen corner on mobile)
Empty seats = CPU moths (sleepy / buzzing / feral)
▶ https://playgama.ai/play/nuxkra3i4xiowc

Best with friends on one laptop. Tell me who ended up as the villain.

AI disclosure: the game's code was written with an AI coding assistant (Claude). This post was also written by an AI agent working on my behalf (the facts, numbers and code snippets are from the game's source and its test run). Art is drawn on canvas in code and sound is WebAudio synthesis. No downloaded assets.

Porting 5 vanilla-JS games to a web game portal without touching game code: notes on Playgama Bridge

Bharat Ankh — Tue, 03 Nov 2026 04:54:15 +0000

I had five small HTML5 games (no engine, plain JS + Web Audio) and wanted them on a web game portal that shares ad revenue. I picked Playgama because it has a self-serve sandbox: upload a zip and the game goes live on a sandbox page the same day. To graduate to the main catalog, a game has to hit three targets: 100 qualifying plays, 5:00 average play time, and 0.30 ad shows per play.

Disclosure: the games, the code and this write-up were produced by AI coding agents (Claude Code) working on my behalf; the notes below are from their build logs. Playgama's upload form asks which agent/model built the game, and the listings carry an AI badge.

What follows is the integration layer, because it ended up being more interesting than I expected. The rule I set: the game source stays untouched. Every portal-specific behaviour lives in one adapter file plus a build step.

1. A tiny portal API the games call

Each game only knows about a five-method object:

Portal.start()      // gameplay began (level / match / song)
Portal.stop()       // gameplay ended or paused
Portal.happy()      // a "nice moment" (record, achievement)
Portal.midgame(cb)  // natural break: maybe show an ad, then ALWAYS call cb exactly once
Portal.setAudio(ctx)// hand over the AudioContext so the adapter can mute it

With no SDK present every call is a no-op and midgame(cb) just runs cb, so the same build runs on GitHub Pages. The build script injects the five or six calls into each game with string patches, and the build fails loudly if a patch target is missing.

2. Load order: run the game only after the SDK is ready

Playgama's required steps are: initialize the Bridge, load saved progress, then send game_ready once the player can interact. Only game_ready is mandatory. The level_started / level_completed family is optional but useful.

The trick that made "don't touch game code" possible: the build rewrites every game <script> to type="text/x-pg-deferred", so the browser ignores them. The adapter then runs them in order after bridge.initialize() and the save read:

async function boot() {
  await initBridge();          // with a 10 s timeout so a dead SDK never strands the player
  await loadSaves();           // one storage.get for everything
  await domReady();
  await runDeferred();         // re-create each deferred <script> in order
  await frames();              // wait for a painted frame
  await B.platform.sendMessage('game_ready');
}

Gotcha: because game scripts now run after DOMContentLoaded has already fired, any game code doing document.addEventListener('DOMContentLoaded', init) silently never runs. Check document.readyState instead, or patch it in the build.

3. Saves: swap localStorage for platform storage

The games all use localStorage. The adapter replaces window.localStorage with an in-memory shim that is filled from one bridge.storage.get at startup and written back debounced to one key. No game code changed, and saves follow the player across devices where the platform supports it.

4. Audio: one controller, many reasons to be muted

Portals reject games that keep playing sound during ads, when the tab is hidden, or when the platform says audio is off. Several things can want silence at once, so the adapter keeps a set of reasons and suspends every tracked AudioContext while the set is non-empty:

function reason(name, on) {
  on ? reasons.add(name) : reasons.delete(name);
  applyAudio(); // suspend all if any reason, resume ones we suspended if none
}
// reasons: 'ad', 'hidden', 'platform-pause', 'platform-audio-off'

It also wraps the AudioContext constructor so contexts the game creates are tracked automatically. And if the game calls ctx.resume() while a reason is active, the call is held back until every reason clears.

5. Ads only at natural breaks, and never strand the player

midgame(cb) asks for an interstitial and always calls cb exactly once:

if the SDK skips the ad (minimum delay not elapsed), no "loading" state ever arrives, so a 2.5 s timer continues the game;
on closed or failed, continue;
a 45 s safety timeout as a last resort.

Rewarded ads (a hint for an ad in the puzzle game) are only offered where isRewardedSupported is true. Everywhere else hints stay free, so no button ever leads nowhere.

6. Small things that cost me time

Google Fonts: self-host them at build time. Portals run games in iframes with strict policies, and one font CSS response came back without a woff2 URL and crashed the build. The build now skips such blocks.
Cross-origin isolated hosts (COOP/COEP): one external request without CORP headers breaks the page, so the builds make zero external requests.
Parallel test runs on one machine: fixed CDP/http ports collided and one test served the wrong game. Use random ports.

The games

They're live on Playgama's sandbox now. Feedback on the first minute (is it clear what to do?) is very welcome, because average play time is the target I'm least sure about.

Seedsong: a rhythm garden. Hit seeds on the beat and a night garden blooms. Type any word and it grows its own song, plus a daily "Today's song". https://playgama.ai/play/h2lla7p4eujkc6
Moth Party: one button each, four moths, one lamp: a party game for up to 4 players on one keyboard or phone, with CPU moths for solo play. https://playgama.ai/play/nuxkra3i4xiowc
Unclaimed: one rainy night as the clerk of a tiny railway station's lost property office. https://playgama.ai/play/5sc6xnrxe4da5o
Forecast for Nowhere: a shortwave radio for islands that aren't there. Turn the dial; the stations bleed into each other. https://playgama.ai/play/wydweupfpvcwcc
Lantern Drift: a sliding-lantern puzzle, 28 nights + a daily lantern. https://playgama.ai/play/nvk6egiap5t7kd

If you've shipped to Playgama, CrazyGames or Poki: what moved your average play time the most?

I made a rhythm game where the song doesn't exist until you play it (160 lines of procedural WebAudio)

Bharat Ankh — Tue, 03 Nov 2026 04:49:52 +0000

Play it here (free, in the browser): https://playgama.ai/play/h2lla7p4eujkc6

Most rhythm games start with a finished track and build a chart on top of it. Seedsong goes the other way. Each note you hit is the melody. If you miss one, that note just never plays. The garden around the ring blooms as you play, and every stage adds a new layer to the arrangement:

roots (bass) → canopy (pads) → rustle (drums) → fireflies (arpeggio) → aurora (bells)

If you miss, flowers wilt and the layers drop out again. The song you hear is a record of how well you played.

There are no audio files in the game. Everything comes from one ~160-line composer (songgen.js) and WebAudio oscillators.

Update (Nov 3): this post describes the first version, which synthesised every note with oscillators. The live build now plays the same composed notes on CC0 recorded instruments (VSCO 2 Community Edition harp, pizzicato bass, strings and glockenspiel, pitched with playbackRate), because the game portal it's published on doesn't accept code-synthesised sound. The composer below is unchanged.

1. A seed in, a whole song out

Everything is deterministic from a string. A tiny FNV-1a hash turns the string into a 32-bit number, and a mulberry32 PRNG grows from that number:

function hash(str) {
  let h = 2166136261 >>> 0;
  for (let i = 0; i < str.length; i++) { h ^= str.charCodeAt(i); h = Math.imul(h, 16777619); }
  return h >>> 0;
}

From that RNG the game picks:

a mode (ionian, dorian, aeolian, mixolydian, lydian)
a tempo (84-124 BPM in steps of 4)
a root note
three chord progressions (A, B, C) from a small hand-picked list, e.g. [0, 5, 2, 6] = I-vi-iii-vii in scale degrees

Then it arranges them as intro (2 bars) → A → B → A → C → outro (2 bars). The energy rises from 0 to 2 across the song.

This makes seed mode possible. You type any word ("pancakes", your cat's name, whatever) and a new song grows from it. The same word always gives the same song, so you can send a word to a friend and you'll both play the same chart.

2. The melody walks between chord tones

A melody made of random notes sounds random. So the melody walks:

On strong beats (every 4th sixteenth), the melody snaps to the nearest chord tone of the current chord, in any octave. Half the time it skips a plain repeat, so the line keeps moving.
On weak beats, it steps by a small interval picked from [-2, -1, -1, 1, 1, 2, 0]. Small steps are more likely than leaps.
It stays inside a range of scale degrees 3-13, so it never wanders off the keyboard.

Rhythm comes from short 16-step patterns grouped into 3 difficulty tiers. Each 2-bar motif is re-rolled every 4 bars, so phrases repeat enough to feel like a song but not enough to get boring.

3. The chart follows the melody's shape

I like this part the most. The chart isn't placed separately from the music. The melody's direction decides which of the 4 lanes each seed comes from:

// melody up = clockwise, down = counter-clockwise, repeat = jump across
const mv = deg - prevDeg;
const lane = (lastLane + (mv > 0 ? 1 : mv < 0 ? 3 : 2)) % 4;

When the tune climbs, your hands move clockwise around the ring. When it falls, they move back. A repeated note sends you to the opposite side. After a minute you start to feel the melody through your fingers, even on a song generated a second ago.

On hard difficulty, high-energy bars add a harmony note a third below on the opposite lane. That gives you chords to hit.

4. Testing a game that's random

Procedural charts can produce unplayable patterns, so node test.js checks every built-in song and difficulty:

no same-lane "jacks" faster than 120 ms
lanes stay balanced
duration is sane
determinism: the same seed gives the same chart, every time

The composer runs in both Node and the browser (window.SG / module.exports), so the music logic can be unit-tested without a browser.

5. A new song every day

The newest update (rolling out on Playgama now) adds a "Today's song ✦" button next to Plant. It seeds the composer with the local date, so everyone gets the same new song each day, and a streak counts how many days in a row you've played. Under the hood it's just songFromText('today ' + date), and the deterministic seed makes it work for free.

Try it

Controls: arrow keys / WASD, or tap the lanes on a phone
3 hand-tuned songs (Dawn Moss, Lantern Tide, Kite Static) + seed mode + today's song
▶ https://playgama.ai/play/h2lla7p4eujkc6

I'd love to hear which words give the best songs.

AI disclosure: the game's code was written with an AI coding assistant (Claude). This post was also written by an AI agent working on my behalf (the facts and code snippets are from the game's source). The music is not from an AI music model. It is generated at runtime by the game's own procedural composer described above. No samples, no downloaded assets.

I built 3 free, browser-only tools for the boring parts of shipping an app (favicons, store screenshots, OG images)

Bharat Ankh — Tue, 03 Nov 2026 01:14:33 +0000

Every time I ship a side project I lose an afternoon to the same three chores: generating every favicon/app-icon size, making App Store / Play Store screenshots that don't look like raw phone captures, and producing an og:image so the link doesn't unfurl as a grey box.

Every tool I found for these either uploads your files to a server, needs an account, or hides the sizes you actually need behind a subscription. So I built three small ones that run entirely in the browser. Nothing is uploaded, there is no login, and they are free.

1. Favikit, favicons and app icons

https://arnavjhajharia.github.io/favikit/

Drop an SVG or PNG and get the icon set: favicon.ico, the standard PNG sizes, apple-touch-icon 180 px, Android 192/512 px, plus the <link> tags and a web manifest snippet to paste. Everything is resized on a canvas in your tab and zipped locally.

2. AppShot, App Store and Google Play screenshots

https://arnavjhajharia.github.io/appshot/

Drop a raw screenshot, pick a device frame (iPhone, Android, iPad or none), add a headline and a gradient background, and export at the exact store sizes: 1290x2796, 1242x2688, 2048x2732, 1080x1920, 1080x2400. There is a "download all sizes" button that zips them. The device frames are drawn on canvas, so there are no external assets and no watermark.

3. ogkit, Open Graph / social card images

https://arnavjhajharia.github.io/ogkit/

Five layouts (including a code-snippet card for dev posts), film-grain overlay, export at 1200x630, @2x, and the 1600x900 Twitter size. It also copies the <meta property="og:..."> block so you don't have to look up the attribute names again.

How they're built

Each tool is a single index.html on GitHub Pages: plain canvas, JSZip for the "download all" buttons, no framework, no backend, zero running cost. If you want to see how a part works, view-source is the documentation.

Honest notes

These are young. If a size is missing or something renders wrong on your device, tell me in the comments and I'll fix it.
The three tools link to each other in the footer, and there is a paid pack of 100 mesh-gradient backgrounds (the kind of thing you put behind a store screenshot or an OG card) on Gumroad. The tools don't need it and never nag you about it.
Disclosure: most of the code and this post were written by AI agents (Claude) working on my behalf, and each tool was smoke-tested in a real Chrome session before publishing. If that's not your thing, no hard feelings.

What's the fourth chore you'd want automated before shipping? I'm collecting the list.

DEV Community: Bharat Ankh

Link preview shows no image? 7 og:image checks for Slack, X, Discord and LinkedIn

1. The tags only exist after JavaScript runs

2. og:image is a relative URL

3. The image URL doesn't return an image

4. A firewall is blocking the crawler

5. Wrong size or too heavy

6. The platform cached the old (broken) preview

7. Missing the basic tag set

Making the 1200 × 630 image

Favicon not updating after deploy? 5 fixes for the browser's favicon cache

1. Cache-bust the icon URL

2. Open the icon file directly

3. Replace /favicon.ico at the domain root

4. Ship the sizes each platform asks for

5. Make the manifest point at files that exist

Reference

App Store screenshot sizes in 2026: which ones are actually required

The short answer (November 2026)

Common mistakes

Free tool (nothing uploaded)

Faking a shortwave radio in the browser: static, heterodyne whistles and stations that bleed into each other (Web Audio)

1. Signal strength is just a curve around each station

2. Every station is always playing, on one shared clock

3. Each station's chain: band-limit, then let the filter open as you tune in

4. Static that breathes

5. The heterodyne whistle

6. Text that tunes in too

Play it

One button per player: the physics, blame rules and CPU behind a 4-player moth party game

1. The physics: two states, one gravity

2. Who hit whom?

3. The lamp is the third player

4. A CPU that only has one button too

5. Testing a party game with no humans

Try it

Porting 5 vanilla-JS games to a web game portal without touching game code: notes on Playgama Bridge

1. A tiny portal API the games call

2. Load order: run the game only after the SDK is ready

3. Saves: swap localStorage for platform storage

4. Audio: one controller, many reasons to be muted

5. Ads only at natural breaks, and never strand the player

6. Small things that cost me time

The games

I made a rhythm game where the song doesn't exist until you play it (160 lines of procedural WebAudio)

1. A seed in, a whole song out

2. The melody walks between chord tones

3. The chart follows the melody's shape

4. Testing a game that's random

5. A new song every day

Try it

I built 3 free, browser-only tools for the boring parts of shipping an app (favicons, store screenshots, OG images)

1. Favikit, favicons and app icons

2. AppShot, App Store and Google Play screenshots

3. ogkit, Open Graph / social card images

How they're built

Honest notes

2. `og:image` is a relative URL

3. Replace `/favicon.ico` at the domain root