📝 Written ● Beginner Updated 2026-05-17

Add a favicon to a /try project

A favicon is usually a folder full of PNGs that the browser fetches as separate files. /try projects are a chat-driven sandbox — they don't have a static-asset folder you can upload binaries into. The workaround is one extra line of HTML: an inline SVG or base64 data URL that ships inside the document. Learn what to ship, why, and the one prompt that gets the agent to do it.

/try is LingCode's web prototyping playground — you describe a site, the agent writes the HTML/CSS/JS, the preview updates live, and a "Publish" button deploys it to a public URL. The project's contents are the agent's code output, not a folder you fill with files. That's lovely for prose-driven iteration and a small constraint when you want a real favicon. This tutorial covers the constraint and the three-line fix.

What you'll learn

Why /try doesn't accept favicon.ico file uploads (and what it does accept)
The four favicon variants browsers actually look for in 2026
How to ship a usable favicon with inline SVG (the modern approach)
The data-URL fallback for browsers that don't take SVG yet
The one-line upgrade to PWA-installable

Step 1: The constraint

/try ships code, not binaries

A traditional favicon setup looks like this: drop favicon.ico, apple-touch-icon.png, and icon-192.png into a /static folder; reference them from your <head>. The browser fetches each as a separate HTTP request.

/try projects don't have a /static folder you can populate from outside the chat. The project is whatever HTML/CSS/JS the agent has produced — image attachments you've sent into the chat get inlined into the agent's code as data URLs, not published as standalone files. That means the conventional favicon pipeline (drop a .ico, reference it) doesn't apply.

The good news: every modern browser supports a favicon as an inline SVG or base64 data URL. You don't need a separate file at all. One line in the <head> does the same job, and that line is well within what /try can ship.

Step 2: What browsers actually look for

Four variants is the full set in 2026

If you read older favicon advice, you'll see lists of 10–14 sizes for "complete browser support." Most of those targeted browsers and devices that no longer exist. In 2026 the realistic set is four:

Variant	Used by	Format
`icon`	Desktop browser tabs, bookmarks	SVG (preferred) or 32×32 PNG
`apple-touch-icon`	iOS Safari "Add to Home Screen"	180×180 PNG, no transparency
`manifest`	Android Chrome "Add to Home Screen", PWAs	192×192 + 512×512 PNGs referenced from a `manifest.json`
`theme-color`	Mobile browser chrome (URL bar color)	A single hex color in a `<meta>` tag

You can ship a v0 site with just the first one. The other three are upgrades for specific scenarios (iOS users saving to home screen, PWA installability, branded mobile chrome).

Step 3: Ship a v0 SVG favicon

One line, no separate file

The simplest workable favicon for a /try site is an inline SVG. Add this to the <head> of your index.html:

<link rel="icon" type="image/svg+xml" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 32 32'><text y='26' font-size='28'>🚀</text></svg>">

That's a 32×32 SVG rendering a rocket emoji as your favicon — no separate file, no upload, works in every Chromium, Firefox, and Safari released in the last three years. Swap the emoji or replace the <text> with a <circle> or <path> for a real logo. The URL-encoded SVG can be as complex as you want; modern browsers parse it inline.

For a non-emoji logo, ask the agent in the /try chat:

Add a favicon to this site. Use an inline SVG showing the letter "L"
in white on a #5B6CFF circle. Put the link tag in <head>.

You'll see the favicon appear in your /try preview's tab within a second of the agent's edit landing. If it doesn't, hard-refresh the preview iframe (the tab caches favicons aggressively).

Why SVG over base64 PNG for the v0 case. Inline SVG is human-editable in the HTML — when you want to change the color or shape, you edit one character. Base64 PNG is opaque; to change anything you regenerate the PNG, re-encode, and replace a long string. For an iterating-fast prototype, SVG wins. Switch to base64 PNG only when you need a specific raster look (photo-style, gradient that's hard to do in SVG).

Don't want to design the SVG yourself? /try generates images for you. The /try agent has a built-in generate_image tool wired to Pollinations AI (free, no key required). Ask "generate a favicon-style image: minimalist purple rocket, flat design, square, 512×512" and the agent returns a hosted image URL it embeds directly into your HTML. For a tab favicon specifically, the URL works as <link rel="icon" href="https://image.pollinations.ai/...."> — though for production, ask the agent to download and inline the result as base64 so your favicon doesn't depend on a third-party service staying up.

Step 4: Add apple-touch-icon for iOS

One more line, base64 PNG this time

iOS Safari ignores SVG favicons for "Add to Home Screen." It wants a 180×180 PNG with no transparency. Since /try can't host the PNG as a separate file, encode it as a data URL:

<link rel="apple-touch-icon" href="data:image/png;base64,iVBORw0KGgo...[long string]...">

Generating the base64 by hand is painful. Ask the agent:

Add an apple-touch-icon for iOS. 180×180, white "L" on a #5B6CFF
background, no transparency. Encode as a base64 data URL and add the
link tag.

The agent will produce a base64 string and inject the <link> for you. The resulting HTML gets larger (a 180×180 PNG base64-encodes to ~10–20KB of text), but that's a one-time payload, not a per-request asset fetch.

Step 5: Upgrade to PWA-installable

Inline manifest, no separate JSON file

For "Add to Home Screen" on Android (and to make Chrome show an install prompt), you need a web manifest. The conventional setup references a /manifest.json file. In /try, inline it as a data URL on the link tag:

<link rel="manifest" href='data:application/json,{"name":"My Site","short_name":"MySite","start_url":"/","display":"standalone","background_color":"%23ffffff","theme_color":"%235B6CFF","icons":[{"src":"data:image/svg+xml,<svg ...>","sizes":"any","type":"image/svg+xml"}]}'>
<meta name="theme-color" content="#5B6CFF">

That's the minimum viable PWA manifest: a name, a start URL, standalone display mode, and one icon. The %23 in the data URL is just a URL-encoded # for the color values. Once this is in place, Chrome on Android will offer "Install app" from its menu, and iOS Safari users get a properly-titled home-screen icon.

This is the kind of thing the agent does well — paste the requirement, get the encoding right on the first try:

Make this site PWA-installable. Add an inline web manifest in the
<head> with name "My Site", standalone display mode, theme color
#5B6CFF, and the existing SVG favicon as the manifest icon. Also add
a theme-color meta tag.

Don't reference external favicon services from a /try project. "Use icons8.com" or "use a CDN favicon" works locally but fails on Publish — many of those hotlink-protect or rate-limit. The published URL gets traffic patterns the original site didn't anticipate, and your "it worked yesterday" favicon stops loading. Inline everything that's load-bearing for your published site.

Step 6: Verify on the published URL

Three checks in 30 seconds

After clicking Publish, run these three checks on the public URL:

Open the published URL in an incognito tab and look at the favicon in the tab strip. If it's the default globe icon, the link tag didn't make it into the published HTML — re-check your edit landed before publishing.
iOS only: open the URL in Safari on a phone, tap the share sheet, tap "Add to Home Screen." Confirm your apple-touch-icon shows in the preview (not the screenshot of the page).
Chrome DevTools → Application → Manifest: confirms the manifest parsed correctly. If you see "Site cannot be installed," there's a syntax error in the inline JSON — usually a missing quote or an unencoded character. The agent will fix it if you paste the DevTools error back.