DEV Community: Iris Khan

Cool Fonts Are Not Fonts: The Complete Guide to Unicode Text Styles

Iris Khan — Tue, 27 Oct 2026 13:58:50 +0000

The first time I built a "font generator," I felt like a fraud. There was no font anywhere in my code. No font file, no CSS, no typeface loading in the background. There was just a table: a list of ordinary letters on one side, and a list of strange, beautiful lookalike characters on the other. When someone typed their name and hit copy, my code quietly swapped every letter for its lookalike, and the result pasted neatly into an Instagram bio as if real styling had happened.

That swap is the entire technology behind cool fonts, and once you see it, you cannot unsee it. Every cursive bio, every gothic gaming name, every circled username you have ever admired is built from characters that Unicode created for completely different jobs: mathematics, television broadcasting, phonetic transcription, and lining up text next to Chinese characters. This guide is everything I have learned about those characters while building with them.

What cool fonts really are

A font is a set of drawings. It tells a device how to paint a character: the letter A stays the letter A, and the font decides whether it gets serifs, curves, or sharp gothic corners. Change the font and the text underneath does not change at all, which is why fonts cannot travel. Paste styled text from a word processor into a plain bio field and the styling falls off, because only the characters made the trip.

Cool fonts work the opposite way. The characters themselves change. When a generator turns "Cool" into 𝐂𝐨𝐨𝐥, it has not bolded anything. It has replaced C (U+0043) with 𝐂 (U+1D402, MATHEMATICAL BOLD CAPITAL C), and done the same for every other letter. The output is a different string that happens to look like your word wearing a costume.

This single fact explains everything else in this guide:

The style survives copy and paste, because the style is the text.
No app needs to support fonts for it to work. Every modern app already renders Unicode.
Nothing can unstyle it. There is no formatting layer to remove, only different characters to replace.
Machines that read text literally, like search engines, screen readers, and databases, see the costume, not your word.

Where the styles actually come from

None of these characters were designed for bios. Each family of styles was borrowed from a serious job, and knowing the original job predicts how the style behaves.

The mathematics block. Most of the big styles, bold, italic, script, Fraktur, double struck, monospace, and the sans serif family, live in one Unicode block called Mathematical Alphanumeric Symbols, U+1D400 to U+1D7FF. Unicode added it in version 3.1, back in 2001, so mathematicians could treat styled letters as different symbols. In mathematics, an italic 𝐴 and a bold 𝐀 in the same formula can mean two different things, so they had to be different characters, not one character in two fonts. The block holds 997 assigned characters, and Unicode's own documentation says they are meant for mathematical notation, expressly recommending against using them in ordinary text as a substitute for real formatting. The whole cool fonts industry is, technically, a misuse the standard warned about in advance.

The borrowed letters. The math block has holes, and the holes are my favorite detail in all of Unicode. Some styled letters were never added to the block because they already existed in an older block called Letterlike Symbols. So the script capital H in your name is ℋ (U+210B, SCRIPT CAPITAL H), the script e is ℯ (U+212F), and the italic small h is ℎ (U+210E), which is officially the Planck constant from quantum physics. In total, 24 characters that belong to the math alphabets actually live in the Letterlike block, and their math block slots are reserved forever. Every good generator stitches the two blocks together so quietly that you never notice. Every bad generator leaves boxes where those letters should be.

The television letters. Circled and squared letters come from Enclosed Alphanumerics (U+2460 to U+24FF) and its supplement. Part of that family was encoded for compatibility with ARIB STD B24, the Japanese digital broadcasting standard, whose symbols labeled broadcast services and program types on screen. The humble bubble letter in a cute username is, by ancestry, Japanese TV infrastructure.

The wide letters. Fullwidth text (Ｃｏｏｌ) comes from the Halfwidth and Fullwidth Forms block, created so Latin letters could share the grid width of Chinese, Japanese, and Korean characters. The vaporwave look is a side effect of lining text up with kanji.

The small letters. Small caps are not really small capitals. They are lookalikes assembled from the IPA and phonetic extension blocks, characters linguists use to transcribe speech sounds. Unicode never promised a full set of them, and there is famously no true small capital X, so generators leave a plain x in its place.

The marks. Strikethrough, underline, and zalgo effects use a different trick entirely: combining marks. These are characters with no width of their own, from blocks like Combining Diacritical Marks (U+0300 to U+036F), that attach to the character before them. One mark gives you é. One overlay mark per letter gives you C̶o̶o̶l̶. Dozens of marks stacked on every letter gives you zalgo, the horror effect named after a 2004 internet meme, which works because Unicode never set a limit on how many marks may pile onto one character.

The styles chart

Here is every major style from the verified mapping table my own tools use, one phrase per row. Notice the script and Fraktur rows quietly borrowing their capital C, F, and H from the Letterlike block.

Style	Specimen	Where it lives	Best first use
Bold	𝐂𝐨𝐨𝐥 𝐅𝐨𝐧𝐭𝐬	Math block	Bio headings, short emphasis
Italic	𝐶𝑜𝑜𝑙 𝐹𝑜𝑛𝑡𝑠	Math block	Quotes, soft emphasis
Bold italic	𝑪𝒐𝒐𝒍 𝑭𝒐𝒏𝒕𝒔	Math block	Names that must stand out
Script	𝒞ℴℴ𝓁 ℱℴ𝓃𝓉𝓈	Math block + Letterlike	Weddings, beauty, signatures
Bold script	𝓒𝓸𝓸𝓵 𝓕𝓸𝓷𝓽𝓼	Math block	Cursive names with better coverage
Fraktur	ℭ𝔬𝔬𝔩 𝔉𝔬𝔫𝔱𝔰	Math block + Letterlike	Gothic and gaming names
Bold Fraktur	𝕮𝖔𝖔𝖑 𝕱𝖔𝖓𝖙𝖘	Math block	Dark aesthetics, metal vibes
Double struck	ℂ𝕠𝕠𝕝 𝔽𝕠𝕟𝕥𝕤	Math block + Letterlike	Techy names, outline look
Sans	𝖢𝗈𝗈𝗅 𝖥𝗈𝗇𝗍𝗌	Math block	Clean, modern profiles
Sans bold	𝗖𝗼𝗼𝗹 𝗙𝗼𝗻𝘁𝘀	Math block	The safest strong style
Sans italic	𝘊𝘰𝘰𝘭 𝘍𝘰𝘯𝘵𝘴	Math block	Minimal captions
Sans bold italic	𝘾𝙤𝙤𝙡 𝙁𝙤𝙣𝙩𝙨	Math block	Bold with a lean
Monospace	𝙲𝚘𝚘𝚕 𝙵𝚘𝚗𝚝𝚜	Math block	Dev and retro profiles
Circled	Ⓒⓞⓞⓛ Ⓕⓞⓝⓣⓢ	Enclosed Alphanumerics	Playful short names
Small caps	ᴄᴏᴏʟ ꜰᴏɴᴛꜱ	Phonetic blocks	Aesthetic captions, subtle style
Fullwidth	Ｃｏｏｌ　Ｆｏｎｔｓ	Fullwidth Forms	Vaporwave, spaced-out headers

A few styles also restyle digits. Bold gives you 𝟎𝟏𝟐𝟑𝟒𝟓𝟔𝟕𝟖𝟗, double struck gives you 𝟘𝟙𝟚𝟛𝟜𝟝𝟞𝟟𝟠𝟡, and circled gives you ⓪①②③④⑤⑥⑦⑧⑨. Italic and script never got digit sets at all, so generators leave your numbers plain in those styles. One more reason to keep prices and dates in normal text.

How generators work under the hood

Under the marketing, a generator is three small ideas stacked together.

Idea one: the mapping table. For block styles, the table is almost embarrassingly simple. Each style starts at a known code point, and every letter is a fixed offset from there. Bold capital A is U+1D400, so bold capital B is U+1D401, and so on. A converter walks your text one character at a time, checks the exceptions list first, then does arithmetic. For assembled styles like circled and small caps, there is no arithmetic, so the table stores the full alphabet as a string and picks by position.

Idea two: the exceptions. This is where beginners get bitten, and I got bitten. If you do pure offset math for script text, the capital H lands on a reserved code point that renders as a box, because the real script H lives in Letterlike Symbols. The fix is a small hand-checked exceptions map: before doing any arithmetic, look the character up, and if it is one of the borrowed letters, use the borrowed code point. It is maybe twenty lines of data, and it is the difference between a generator that looks professional and one that quietly breaks on the name "Hannah."

Idea three: counting honestly. Almost every character in these blocks sits above U+FFFF, outside the Basic Multilingual Plane. In JavaScript and every UTF-16 system, each one is stored as a surrogate pair, two code units. I verified this against my own table while writing this guide: the four visible letters of 𝐂𝐨𝐨𝐥 report a .length of 8, while spreading the string into code points gives the true count of 4. Any code that measures, slices, or validates styled text must count code points (Array.from(text).length), or limits will lie and slices will cut characters in half.

After conversion, one more invisible thing can happen to your text: normalization. Some systems run input through a Unicode process called NFKC, which folds compatibility characters back to their plain forms. I tested this too: NFKC turns 𝐂𝐨𝐨𝐥, Ⓒⓞⓞⓛ, and Ｃｏｏｌ all back into "Cool". But it does nothing to ᴄᴏᴏʟ, because small caps characters are real phonetic letters with no plain equivalent to fold into. This is why the same styled name can survive in one app and come out plain in another.

The hidden costs

Cool fonts are not free. You pay in three currencies, and anyone using them deserves the full price list.

Cost one: accessibility

A screen reader cannot see your costume. It reads the actual characters, and for math block letters that usually means reading the full Unicode names, one letter at a time. A bold name can be announced as "mathematical bold capital A, mathematical bold small m..." all the way through the word, and some tools skip the characters entirely and read nothing at all. Neither outcome is your name.

This is not just a vibe, it is a documented failure. The W3C's accessibility guidelines include a named failure, F71, for using lookalike characters without a text alternative, under Success Criterion 1.1.1 (Non-text Content). The official example is a word that looks like "cook" but is built from Greek and Cyrillic letters, which a screen reader announces as "Greek small letter lunate sigma, Cyrillic small letter o, Greek small letter omicron, k." Accessibility writers list social media text styled with mathematical alphanumeric symbols as the same failure pattern, and Braille displays have it worse, because Braille cells follow the actual characters too. One styled line in a bio is a decoration. A styled paragraph is a locked door.

Cost two: nobody can find you

Search works on characters, so a styled word is a different string from the word people type. Your styled display name will not match a normal search for your name, a styled hashtag will not join the real hashtag's feed, and Ctrl+F on a page will sail straight past styled text without matching it. Whether a platform rescues you depends on whether it normalizes text behind the scenes, which is inconsistent and undocumented in most apps. My rule from experience: style for the people already looking at your profile, and keep at least one plain line, your real name, your niche, your city, for the people still trying to find you.

Cost three: the security shadow

The same lookalike trick has a dark mirror. Unicode publishes a file called confusables.txt, maintained under its security standard UTS #39, cataloguing characters that look alike across scripts, because attackers register domains and usernames with Cyrillic or Greek letters swapped in for Latin ones. These IDN homograph attacks have been known since a 2001 paper demonstrated the idea by registering a lookalike of a major software company's domain, and browsers still defend against them by sometimes showing a domain's ugly punycode form instead of the pretty one. Fancy math letters are a small, mostly harmless corner of this world, but the lesson transfers: text that looks identical is not necessarily the same text, and duplicate checks and moderation filters that compare raw strings can be fooled by styled spam. Use the costume for yourself, never to look like somebody else.

Where cool fonts work, and where they break

Behavior varies by platform, because every platform made its own choices about validation, fonts, and normalization. The patterns I rely on:

Instagram and TikTok bios: the natural habitat. Styled display names and bio lines render well on modern phones. Keep hashtags plain, because styled hashtags do not join the real feed; the searchable username underneath stays plain Latin anyway.
X (Twitter): display names accept styled characters, but X's published weighting system charges more for characters outside the basic ranges, so styled text eats your limit faster than it looks.
Discord: display names and server nicknames are the playground; the actual username is restricted to lowercase letters, numbers, underscores, and periods, so no style survives there. Server admins can also rename you, and people need to be able to type your name to @mention you.
Games: the strictest filter of all. Many games allowlist plain ASCII plus a few scripts for usernames and reject everything else, or show boxes. Bold and sans styles have the best survival rate; exotic styles and heavy zalgo get rejected or clamped first.
LinkedIn and professional profiles: the characters usually render, but think twice. Recruiters search by plain text, applicant tracking systems parse by plain text, and a styled headline can quietly remove you from both. Keep the name and headline completely plain here.
Email and documents: styled text in a subject line can trip spam filters (styled letters have shown up in spam for years, because lookalikes dodge keyword filters), and in documents it breaks find, sorting, and copy into other systems.

Underneath all of this sit two forces: font coverage (no glyph means an empty box, called tofu, and older budget Android phones are the classic victims, especially for circled letters) and the platform's own pipeline, which may normalize your text back to plain on save or clamp long combining mark runs, so your zalgo arrives tamer than you sent it.

How to use cool fonts well

Everything above compresses into one checklist, the same one I give everyone.

Style names and headings, never body text. One or two styled lines per profile. The moment information matters, plain text takes over.
Keep a plain twin. Your real name or keyword, typed normally, somewhere on the same profile. Decoration for the eye, plain text for the machines.
Never style anything that must match exactly. Email addresses, discount codes, booking references, Wi-Fi passwords, and hashtags. Styled characters break matching silently.
Pick boring styles for important places. Sans bold and bold are the most widely supported and the most readable. Script and Fraktur are treats for short strings only.
Count double. Budget two characters for every styled letter wherever a limit is tight.
Test like a stranger. Paste the result on the oldest phone you can borrow, and once, just once, listen to your profile through a free screen reader. Ten minutes that will permanently change how much you style.
One accent per name. A styled word or two inside a mostly plain name reads as personality. A fully styled everything reads as a puzzle.

Which style for which job

Wedding, beauty, celebration: script for elegance, bold script when you need it to survive more phones. Keep it to names.
Gaming: Fraktur or bold Fraktur for the dark look, double struck for a cleaner outline style. Check the game's filter with a throwaway name first.
Business and creators: sans bold for headings. Intentional, professional, and it renders almost everywhere.
Playful and cute: circled letters, in short bursts. Weakest support on old devices, so never for your only name.
Subtle and aesthetic: small caps. The quietest style here, and the one that survives normalization filters because the characters are real letters. Still invisible to search, so pair it with plain text.
Retro and vaporwave: fullwidth and monospace. Maximum spacing, maximum nostalgia.
Memes and horror: zalgo, lightly. A little goes a long way, heavy zalgo is hostile to screen readers and gets clamped by platforms anyway.

FAQ

Are cool fonts safe to use? Will I get banned?
The characters are ordinary Unicode text, not hacks or exploits, and mainstream platforms allow them in display names and bios. What can get you in trouble is impersonation: styling your name to look like someone else's fools people the same way a lookalike domain does. Be yourself, just fancier.

Why does my styled text turn into boxes on some phones?
The phone has no glyph for those code points, so it draws an empty box called tofu. It is a font coverage problem on the viewing device, not something wrong with your text. Simpler styles, especially bold and sans bold, are covered by far more devices.

Why did my styled name become plain text after I saved it?
The platform probably normalized your input with NFKC or a similar process, which folds most styled characters back to plain letters. Small caps and upside down styles often survive, because their characters have no plain form to fold into. If a name matters, test it on the actual platform before announcing it.

Do styled letters count as one character or two?
One character to a human, two code units to JavaScript and other UTF-16 systems, because each is stored as a surrogate pair. That is why limits drain at double speed, and why developers count code points instead.

Can I use cool fonts in hashtags and usernames?
Hashtags, no: a styled hashtag is a different string and will not join the real conversation. Usernames, mostly no: platforms like Discord restrict usernames to plain lowercase letters, numbers, underscores, and periods. Display names are where the styling belongs.

Is there a way to make styled text accessible?
On the open web, yes: pair the styled text with a real text alternative, which is exactly what WCAG failure F71 asks for. In a bio field, you cannot attach alternatives, so the practical fix is the plain twin rule: the same information, in normal characters, right next to the styled version.

By Iris Khan, beginner web dev, writing the build in public.

Related Guides

The Hidden Price of Fancy Text: What Those Curly Bio Letters Actually Cost You
How Unicode Text Styling Actually Works
Bold Text Generator: Bold Fonts for Captions, Bios and Posts
Fancy Letters A to Z: Copy and Paste
Fancy Font Styles: the open chart and code resource behind the styles in this guide, with the full mapping table you can copy into your own projects.

The Hidden Price of Fancy Text: What Those Curly Bio Letters Actually Cost You

Iris Khan — Thu, 22 Oct 2026 12:16:38 +0000

I build text styling tools. I also spend an unreasonable amount of time reading the Unicode standard. Here is what styled text does to your character limits, your search visibility, and anyone using a screen reader, with the receipts.

Somewhere on your phone right now there is a bio written in letters like 𝒯𝒽𝒾𝓈. It looks like a font. Your phone treats it like one. And almost everything about how it behaves is different from what you think.

I know because this is my whole thing. I am Iris, a beginner web developer, and I built a small Unicode text styler called Fonti that turns plain typing into 350+ styled versions you can copy into bios and captions. Building it forced me to learn what these characters actually are, and the honest answer surprised me: the styles are a clever hack on top of a system that was never designed for decoration, and the hack has real costs. This article is the full accounting, with proof for every claim, because the internet is full of font generator pages and almost none of them tell you any of this.

First, the proof of what these characters are

Open the official Unicode code charts (unicode.org/charts, the Mathematical Alphanumeric Symbols chart) and you will find the smoking gun. The letters in your bio are not a font file. They are individual characters living in a block called Mathematical Alphanumeric Symbols, U+1D400 to U+1D7FF, a block the Unicode Consortium created so mathematicians could write variables in different styles inside equations.

Three details from that chart prove how improvised the whole styling system is:

1. Some letters are simply missing. Look for the script small h. It is not there. The slot U+1D4BD exists, but the plain script capital H, C, and several others were never encoded in this block, because those shapes already existed elsewhere in Unicode as science symbols (ℋ is U+210B, SCRIPT CAPITAL H, from the Letterlike Symbols block). Generators quietly borrow those. Your "one font" is a patchwork stitched from at least two different Unicode blocks.

2. One letter is a physics constant. The italic small h every generator uses is ℎ, U+210E, the PLANCK CONSTANT. It was borrowed because the real mathematical italic h (at U+1D455) was never encoded at all. So when your name is written in italic script, the h in it is, formally, a unit of quantum physics.

3. Nobody designed these to match. Because the glyphs come from math notation, there was never a promise of consistent weight, spacing, or coverage. That is why some styles look slightly off, and why a few letters in a fancy style sometimes render in a visibly different design: the generator substituted the closest character it could find.

This is all verifiable in about two minutes with a character inspector: paste a styled word into any Unicode analyzer and read the code points. I check mine against the chart constantly, because my users paste the output into profiles that matter to them.

Cost one: your characters count double

Every character above U+FFFF, which includes every mathematical alphanumeric letter, is stored in UTF-16 as a surrogate pair: two code units instead of one. Most platforms count characters in ways that feel this, even when they do not explain it.

Here is the arithmetic for Instagram's 150-character bio limit. Take the name "Amelia" in bold script: 𝓐𝓶𝓮𝓵𝓲𝓪. That is 6 visible letters and 12 UTF-16 code units. Add a partner's name, a date, and two hearts, and a bio that looks short can hit the limit while looking half empty. I have watched users of styled text trim their bios three times without understanding why the counter moved so fast. Now you know: styled letters are heavy.

X (Twitter) has its own published counting system (the twitter-text configuration, public on GitHub) where characters are weighted, and characters outside the basic ranges weigh more. The details differ by platform, but the direction is always the same: decoration costs space.

Cost two: search cannot see you

Search engines match text by characters. The styled 𝒜 (U+1D49C-ish family) is not the letter A (U+0041), and to a search index they are different things unless the platform normalizes them.

You can test this yourself. Put a unique styled word in a post, then search the platform for the same word typed normally. On most platforms, you will not find it. This is the trade nobody mentions: a styled display name is decoration for people who already found you, and invisibility for people searching your name. My standing advice, which I give to Fonti users too, is one styled line for looks and one plain line for being found. Keep your real name, your city, or your business keyword in plain text somewhere on the profile.

There is a second, quieter version of this problem. Some systems apply Unicode normalization (a process called NFKC) that folds many styled characters back toward plain ones, and some do not. That is why the same styled name can be searchable in one app and invisible in another. There is no standard behavior, because decoration was never part of the design.

Cost three: accessibility, and this is the serious one

A screen reader does not see a styled word as a word. It reads character names or letter-by-letter approximations. The name 𝒥𝑜𝒽𝓃 can be announced as a string of "mathematical script capital J, mathematical bold script small o..." instead of "John". For a blind follower, your clever bio is a minute of robot spelling.

This is not a theoretical concern. The Web Content Accessibility Guidelines (WCAG) exist because text is supposed to be text: selectable, searchable, readable by machines, and understandable by everyone. Styled Unicode fails most of that quietly. It still copies, it still looks fine to sighted readers, and the failure only shows up for the people least able to tell you about it.

The second accessibility cost is visual. On devices whose fonts lack glyphs for the math block (older Android phones are the classic case), styled letters render as empty boxes, the phenomenon developers call tofu. Your name becomes ▯▯▯▯. The older the phone, the more likely the boxes, which is why wedding and family accounts feel this cost first: the relatives you most want to read your bio are holding the phones least likely to render it.

So why does any of this work at all?

Because Unicode is the one text system every platform already speaks. A font file needs installation and app support. A Unicode character just travels: copy it on one phone, paste it into another app, and it arrives intact, because it was never a picture of text. It is text, wearing a costume from the mathematics department.

And honestly, the costume is delightful. A gaming name in blackletter, a couple's names in script, a small business bio with one elegant styled line: these genuinely make profiles feel personal in feeds that all look the same. I would not have built a styler if I did not believe that. The point of this article is not "never use fancy text." The point is to use it like someone who knows the price list:

One styled line, max two. Style the display name or one bio line. Keep everything functional (dates, contact info, links-in-bio text) plain.
Always keep a plain-text twin. Your searchable name or keyword, typed normally, somewhere on the profile.
Test on the oldest phone you can borrow. If your name is boxes there, simplify the style. Bold script survives far more devices than delicate script.
Never style anything that must be copied exactly. Booking references, email addresses, discount codes, Wi-Fi passwords. Styled characters will break matching systems silently.
Count double. When a field has a tight limit, budget two characters for every styled letter and you will never be surprised mid-paste.

The receipts, if you want to check me

Everything above can be verified without trusting me:

The Unicode code chart for Mathematical Alphanumeric Symbols (U+1D400 to U+1D7FF) on unicode.org shows the block, the gaps, and the borrowed letterlike symbols (ℋ U+210B, ℎ U+210E).
Any online UTF-16 length checker will show a styled name counting roughly double its visible letters.
X's text-counting rules are published in the twitter-text repository on GitHub.
A free screen reader (NVDA on Windows, VoiceOver on iPhone) reading a styled bio aloud is the fastest proof of the accessibility cost. Try it once and you will never style a full paragraph again.

I keep a running set of guides on the practical side of this: which styles survive which apps, tested one by one. If you want to play with the styles themselves and see the character counts as you type, that is exactly what I built Fonti for. It is free, it runs in the browser, and after this article you will use it with your eyes open, which is the only way I want anyone using it.

Decoration is fine. Decoration you do not understand is a tax you pay in reach, in space, and in the people who quietly cannot read you. Now you know the tax code.

Try the styles: every alphabet in this article is charted in the free Fancy Font Styles project on GitLab.

How Unicode Text Styling Actually Works (2026)

Iris Khan — Mon, 19 Oct 2026 10:46:18 +0000

Your bio "fonts" aren't fonts. They're just characters: weird, wonderful, off-the-map characters. Here's the technical story of how they work, why they sometimes turn into tofu boxes, and what every dev should know before using them.

I've been building Fonti (a little Unicode text styler) in public for a while now, and the number one question I get from developer friends is some version of: "Wait, how is this not just a font?"

Fair question. On the surface it looks like a font change. You paste 𝕙𝕖𝕝𝕝𝕠 into your bio and it renders "fancy." But no font was installed, no CSS was applied, nothing was styled at all. So what actually happened?

This is the article I wish someone had handed me when I started: the real mechanism, the failure modes, and the honest limitations, from one beginner dev to other devs.

The trick: it's not styling, it's substitution

Every character you see on screen is a code point: a number assigned by the Unicode standard. The letter h is U+0068. Normal stuff.

But Unicode also contains entire styled copies of the alphabet, originally designed for math notation. The big one is the Mathematical Alphanumeric Symbols block (U+1D400 – U+1D7FF). When a generator turns hello into 𝐡𝐞𝐥𝐥𝐨, it's doing plain substitution:

h (U+0068) → 𝐡 (U+1D421, MATHEMATICAL BOLD SMALL H)
e (U+0065) → 𝐞 (U+1D41E)
…and so on.

That's it. There's no formatting layer. The "style" is baked into which characters you picked. This is why it works everywhere text works, from Instagram bios and Discord usernames to tweets and plain <textarea> elements: those places render characters, and these are valid characters.

Try it: paste 𝐡𝐞𝐥𝐥𝐨 into any input, any app, any OS. It renders styled (if the glyph exists) without a single line of CSS.

Some copy-paste examples

Here's what the generator approach produces, all plain Unicode:

Bold: 𝐡𝐞𝐥𝐥𝐨 𝐰𝐨𝐫𝐥𝐝
Italic: ℎ𝑒𝑙𝑙𝑜 𝑤𝑜𝑟𝑙𝑑
Bold italic: 𝒉𝒆𝒍𝒍𝒐 𝒘𝒐𝒓𝒍𝒅
Script (cursive): 𝒽ℯ𝓁𝓁ℴ 𝓌ℴ𝓇𝓁𝒹
Fraktur (gothic): 𝔥𝔢𝔩𝔩𝔬 𝔴𝔬𝔯𝔩𝔡
Double-struck: 𝕙𝕖𝕝𝕝𝕠 𝕨𝕠𝕣𝕝𝕕
Monospace: 𝚑𝚎𝚕𝚕𝚘 𝚠𝚘𝚛𝚕𝚍
Sans-serif bold: 𝗵𝗲𝗹𝗹𝗼 𝘄𝗼𝗿𝗹𝗱
Circled: ⓗⓔⓛⓛⓞ ⓦⓞⓡⓛⓓ
Small caps (not really, but fun): ʜᴇʟʟᴏ ᴡᴏʀʟᴅ

Notice how the "script" row mixes blocks. That's normal. Generators typically pull from several Unicode ranges and fall back to the closest match for letters that don't have a styled twin.

Why some glyphs turn into tofu boxes ▯

You've seen it: you paste a style somewhere and get ▯▯▯▯▯ or blank squares. That box is called tofu, and the reason is simple: the user's font doesn't have a glyph for that code point.

Unicode assigns the number; fonts decide how (or whether) to draw it. The Mathematical Alphanumeric Symbols live at U+1D400+, which is in the supplementary planes, outside the Basic Multilingual Plane (U+0000–U+FFFF) that most legacy fonts cover. Common system fonts on iOS/Android/modern desktop cover them fine, but:

Older Windows fonts often don't include U+1D400–U+1D7FF.
Some platforms apply their own font stack to usernames/bios and won't do proper fallback.
A few apps actively strip non-BMP characters (see below).

So "works on my phone" ≠ "works everywhere." It's a font coverage problem, not a Unicode problem.

The part devs always ask about: surrogate pairs and string length

Here's where it bites in code. Characters above U+FFFF can't fit in one UTF-16 code unit, so UTF-16 (JavaScript strings, Java, .NET) encodes them as a surrogate pair: two code units per character.

Watch this:

"𝐡".length        // 2, not 1!
[..."𝐡"].length   // 1: the spread operator iterates code points
"𝐡𝐞𝐥𝐥𝐨".length   // 10, not 5

Five visible "letters," ten UTF-16 code units. This is why:

Character limits break. A platform counting with .length sees "hello" styled as 10 characters. Twitter/X bio limits, Discord's username length checks, database VARCHAR(30) columns. They all count code units, not glyphs. A 75-char display name can blow past a 32-char limit while looking half the size.
Slicing breaks. "𝐡𝐞𝐥𝐥𝐨".slice(0, 3) gives you 𝐡 + half of 𝐞: a dangling surrogate, which renders as � (U+FFFD, the replacement character).
Emojis have the same problem, for the same reason. If your validation already handles emoji correctly (code-point-aware), styled text mostly behaves.

Rule of thumb: whenever you measure, slice, or validate user text, count code points ([...str].length, Python's len() on a str, etc.), not code units.

Why some platforms strip or reject styled text

A few reasons you'll hit in the wild:

Normalization. Some backends run input through NFC normalization. Most math-alphanumeric chars survive it, but combining-mark-based styles (z͟a͟l͟g͟o͟ text, diacritic stacks) get mangled.
Character filters. Games and chat apps often allowlist printable ASCII + a few scripts. Anything else gets replaced or rejected. This is why a style works on TikTok but fails in a game's username field.
Rendering pipelines. Discord, for instance, renders usernames in specific fonts in some UI spots; coverage varies between desktop, mobile, and web.
Spam heuristics. Heavy zalgo/combining text can trip abuse filters. Another reason to keep it clean.

If you're building anything that accepts display names, the pragmatic approach is: allow the full range, count code points, and set generous limits.

Honest limitations (the part most generators won't tell you)

Screen readers. A screen reader doesn't read 𝐡𝐞𝐥𝐥𝐨 as "hello." Many announce it as "mathematical bold small h, mathematical bold small e…", letter by letter, with the style prefix. An entire styled bio can be an awful experience for blind users. Use styled text sparingly, never for essential info.
Search and Ctrl+F. Searching a page for "hello" will not match 𝐡𝐞𝐥𝐥𝐨. Different code points, no match. Same reason Google treats them as distinct strings.
It's not a font. You can't change weight, size, or color beyond the fixed variants Unicode provides. There's no "bold script Fraktur with serifs." The set is closed, and new styled alphabets basically never get added (Unicode's policy is now not to encode more styled Latin letters).
Copy-paste fidelity. Pasting between apps with different font coverage can silently turn characters into tofu or question marks on the receiving end.
Readability. Fraktur and double-struck look cool and are genuinely hard to read. Long paragraphs in styled text are a readability tax on everyone.

None of this means "don't use it." It means use it like seasoning, not the whole meal.

FAQ

Are styled Unicode characters the same as fonts?
No. Fonts change how a character looks. Styled Unicode swaps in different characters that happen to look styled. The style travels with the text because it is the text.

Why does my styled name show as boxes on some devices?
The device's fonts lack glyphs for those code points (usually U+1D400+). It's a font-coverage issue on the rendering side. The characters themselves are fine.

Do styled characters count as one character or two?
One code point, but two UTF-16 code units (a surrogate pair). "𝐡".length === 2 in JavaScript. Count code points, not code units, when validating input.

Will styled text work in every app?
Mostly, but not always. Some games and platforms filter non-standard characters, and font coverage varies. Test the specific style on the specific platform before committing to it.

Is using styled Unicode in a bio "hacking"?
No, it's just Unicode. Platforms render what you paste. Some platforms filter it, which is their right, but there's nothing exploit-like about pasting valid characters.

Can I make my own styled alphabet?
Not really. You can't add code points to Unicode. What generators do is map existing styled characters onto ASCII input. You can build your own mapping tables (that's literally how these tools work), combining different blocks creatively.

Does styled text hurt SEO or accessibility?
For SEO: search engines see distinct code points, so styled keywords don't match plain-text queries. For accessibility: screen readers often spell out the style names letter by letter, which is rough. Keep styled text decorative and short.

Why do some letters look "missing" in certain styles?
Unicode never encoded styled versions of every letter in every style. Generators substitute the closest available character or leave the plain letter. For example, there's no dedicated "script capital" for every letter, so mappings get creative.

Related Guides

If you want to play with the actual styles after understanding the machinery, a couple of practical roundups I put together: Best Fonts for Instagram Bio 2026 (30 copy-paste styles, tested), Aesthetic Text Styles 2026 (vibe-organized, from coquette to dark academia), and for the gamers, Gaming Name Fonts (what actually survives game username filters). Also worth a look: TikTok bio fonts guide, Discord name fonts guide, WhatsApp text formatting guide, and Fancy text generators, under the hood. Gaming name fonts guide

By Iris Khan, beginner web dev, writing the build in public.

Go deeper: The Hidden Price of Fancy Text: What Those Curly Bio Letters Actually Cost You covers what styled text does to your character limits, search visibility, and screen readers, with the receipts from the Unicode standard itself.

The full mapping table behind these styles lives in a public GitLab snippet, the Unicode Font Styles Mapping Table, and every alphabet is also published as a copy-paste chart in the Fancy Font Styles project.

I Went Quiet for a Month. Here Is What I Was Overthinking.

Iris Khan — Mon, 12 Oct 2026 19:15:21 +0000

This is part 5 of my beginner journey, and I owe you an apology first.

I went quiet for about a month. This is my first real project, and I did not know how much time it would take. For people who build things every day, a lot of this will look basic. For me it was a big deal, and I did not want to post updates until I had something honest to say.

If you are new here, the earlier parts are part 1, part 2, part 3 and part 4.

The name took the longest

I started with the name Fontly and deployed the site under it. Then I did my research. I found that domains in the same niche already existed, and so did apps with similar names. I started worrying about brand and copyright problems. Then I learned that people can actually take legal action over a name, and that made the worry bigger.

So I kept searching. I wanted a name that was short, easy to say, and related to the site. I did not want a long name. Every option I liked had some problem.

And there was a quiet pressure on top of it. Why was I taking so long to decide one thing? That feeling made me overthink even more.

In the end I said: enough. Close your eyes and pick Fonti.

Renaming after I had already deployed

Here is the funny part. The site was already deployed under the old name, so I had to go back and change everything to Fonti.

And a confession. In part 4 I already talked about the new name, but at that time I had not even bought the domain. When it was finally time to buy it, the overthinking came back and it took more time again. This time I stopped thinking and took action.

It might sound weird, or even funny. But I think this is what happens when you are new to something. A small decision feels huge when you are afraid of getting it wrong.

Then my PC died

In the middle of all this, the motherboard and the processor on my PC both died. I replaced them and started again.

It was frustrating. But it reminded me of part 1 and part 2. When I get stuck, my first instinct is to think more. Every time I took action instead, things moved again.

I chased speed, then stopped

Speed was the top priority for my site. I started chasing it hard, and I reached a level that most beginners do not even think about.

Then I stopped. Overdoing anything is unhealthy, and speed is no exception. After a certain point it becomes overkill: every small gain costs more time than the one before it, and that time was being taken from things that still needed finishing. A faster site is nice. A finished site is better. So I decided that "fast and good enough" is the goal, not "perfect".

One technical thing from this month

I also overthought whether my code was correct. After part 4 I had an exception list for the Unicode holes, and I did not want to trust my memory. So I wrote a script that runs every style on A to Z, a to z and 0 to 9, and checks two things:

Never U+FFFD: the replacement character means something went wrong.
Never unchanged: a letter should not come back as itself, unless I declared on purpose that it should.

Here is the idea, simplified:

function checkOne(style, plain, generated, kind) {
  const cp = generated.codePointAt(0);

  if (cp === 0xfffd) {
    failures.push({ subject: style.id, cause: `${kind} "${plain}" produced U+FFFD` });
  }

  if (generated === plain && !isDeclared(style, plain, kind)) {
    failures.push({ subject: style.id, cause: `${kind} "${plain}" passed through unchanged` });
  }
}

I ran it:

RESULT: PASS. 17 styles, all uppercase/lowercase/digit characters verified. 8 decorations, every prefix and suffix character verified.

I felt safe. But a passing test only tells me it did not find a problem. It does not tell me it was able to find one.

So I tested the test. In my script style, each exception lives in a substitutions list. I deleted one line, B: 0x212c, which brings back the exact bug from part 4. Then I ran the script again:

RESULT: PASS. 17 styles, all uppercase/lowercase/digit characters verified. 8 decorations, every prefix and suffix character verified.

It still passed. And the line for B in the output said:

B -> 𝒝  (U+1D49D)

That is a code point in one of the holes. The bug was back, and my test was happy.

The reason is simple. U+1D49D is not U+FFFD, and it is not the same as the plain B. JavaScript accepted the number without complaint, because String.fromCodePoint(0x1D49D) gives a perfectly valid string. The empty box only appears later, when a screen tries to draw it. As far as I can tell, U+FFFD shows up when text is decoded from broken data, not when you build a string from a number. So my first check could never catch this.

The fix was to ask Unicode directly. JavaScript regular expressions have a property for it: \p{Cn} means "a code point that has not been assigned".

const UNASSIGNED = /\p{Cn}/u;

if (UNASSIGNED.test(generated)) {
  failures.push({
    subject: style.id,
    cause: `${kind} "${plain}" produced ${codePointHex(generated)}, a code point Unicode has not assigned`,
  });
}

With the line still deleted, the script now says:

RESULT: FAIL. 1 failure(s):
  [script] uppercase "B" produced U+1D49D, a code point Unicode has not assigned

I put the line back and ran it once more. PASS, and this time it means something.

Two honest limits. First, \p{Cn} depends on the Unicode version inside whatever runs the code. On my computer, Node reports Unicode 17.0 (process.versions.unicode), and an older runtime might think a newer character is unassigned. So I only run this check on my own machine, never in the browser. Second, assigned does not mean visible: a valid character can still show as a box on a device whose fonts do not have it. So PASS means no holes. It does not mean it works everywhere.

What I learned

Overthinking costs more than a small mistake: a name does not need to be perfect. It needs to be good enough to start.
Things break in boring ways: a dead PC and a rename took as much time as any clever bug.
Break your code on purpose, once: if the test does not fail, it was not protecting you.

What is next

I have been building more than I have been posting. In the next part I will show you the site live, and tell you the full story of how it came together.

One question for you: what is one decision you overthought on your first project, and how did you finally make it?

Copy-Paste Fonts Are Not Fonts. Here Is What Broke My Code

Iris Khan — Wed, 02 Sep 2026 17:27:28 +0000

This is part 4 of my beginner journey.

In part 1 I did not know what to learn first. In part 2 I stopped overthinking and picked a project: Fonti, a free copy-paste font generator. In part 3 I chose my tools (Astro, Git, Cloudflare Pages) and promised the next post would be about the actual build.

NOTE: I renamed the project from Fontly to Fonti since part 3. Same tool, better name.

This is that post. My first real code of this series.

And it starts with me being completely wrong about how these tools work.

What I thought I was building

My idea was simple. The user types text. I apply a font. They copy it and paste it into their Instagram bio.

I spent a few days confused about one part of that plan. How does a font survive a copy-paste? If I load a font on my website, that font lives on my website. Instagram does not have it. So how does the style travel?

The answer is that it does not. There is no font. There never was.

The real trick

When you paste 𝐛𝐨𝐥𝐝 text somewhere, you are not sending style information. You are sending different characters that are shaped like bold letters.

The b in that bold word is not the letter b. It is a math symbol that looks like a bold b.

Unicode has a block called Mathematical Alphanumeric Symbols. It lives at U+1D400 to U+1D7FF. It has 1024 slots, 996 of them are used, and 28 are empty on purpose. It was added in Unicode 3.1 in the year 2001.

Why does it exist? Because mathematicians need 𝐴 and 𝔸 and 𝒜 to mean three different things in the same paper. In math, the style is part of the meaning. So Unicode gave each style its own real character.

Social media users then found these characters and started using them for stylish bios. That is the whole industry of "font generators".

So my tool is not a font tool. It is a lookup table. That is it.

This also connects back to something from part 3. I chose Astro because it sends very little JavaScript by default, and only sends it where the page really needs it. Now I know exactly what that JavaScript is: one small function that swaps characters. Everything else on the site can stay as plain HTML.

My first version

If the styled letters are stored in alphabetical order, then converting text is just simple math.

Normal A is at U+0041. Bold A is at U+1D400. So I take the letter's number, subtract the start of the normal alphabet, and add the start of the bold alphabet.

const OFFSETS = {
  bold:         { upper: 0x1D400, lower: 0x1D41A },
  italic:       { upper: 0x1D434, lower: 0x1D44E },
  script:       { upper: 0x1D49C, lower: 0x1D4B6 },
  fraktur:      { upper: 0x1D504, lower: 0x1D51E },
  doubleStruck: { upper: 0x1D538, lower: 0x1D552 },
  sansSerif:    { upper: 0x1D5A0, lower: 0x1D5BA },
};

const convert = (text, style) => {
  const { upper, lower } = OFFSETS[style];

  return [...text].map((ch) => {
    const code = ch.charCodeAt(0);
    if (ch >= "A" && ch <= "Z") return String.fromCodePoint(upper + code - 65);
    if (ch >= "a" && ch <= "z") return String.fromCodePoint(lower + code - 97);
    return ch;
  }).join("");
};

I was happy. It felt clean. No font files, no library, no dependency. Just math.

Bold worked. Italic mostly worked. Sans-serif worked.

Then I tested script style and got this:

𝒜 for A. Then an empty box for B.

Why it broke

The block has holes in it. And the holes are there on purpose.

Before this big math block existed, Unicode had already added a few of these styled letters in a different block called Letterlike Symbols at U+2100 to U+214F. They were added because people already used them as single math symbols. Things like ℝ for real numbers and ℋ for a Hilbert space.

So when the big block was designed later, those letters were left out. Unicode did not want to encode the same character twice. The official Unicode chart says this directly about the double-struck letters: they are "omitted here to avoid duplicate encoding."

The result for me is simple. My math formula was pointing at empty slots. Empty slot means empty box on screen.

I had to build an exception list. Here is every hole that affects normal A to Z text, and where the real character actually lives:

const EXCEPTIONS = {
  italic: {
    h: "\u210E",                                    // ℎ  (Planck constant)
  },
  script: {
    B: "\u212C", E: "\u2130", F: "\u2131", H: "\u210B",
    I: "\u2110", L: "\u2112", M: "\u2133", R: "\u211B",
    e: "\u212F", g: "\u210A", o: "\u2134",
  },
  fraktur: {
    C: "\u212D", H: "\u210C", I: "\u2111",
    R: "\u211C", Z: "\u2128",
  },
  doubleStruck: {
    C: "\u2102", H: "\u210D", N: "\u2115", P: "\u2119",
    Q: "\u211A", R: "\u211D", Z: "\u2124",
  },
};

That is 24 exceptions in four styles.

Now look at which styles are not in that list. Bold, bold italic, bold script, bold fraktur, sans-serif and sans-serif bold are all fine. Their letters sit in one clean run with no gaps. Pure math works perfectly for them.

Only the four styles that overlap with old math notation are broken. That makes sense once you know the history, and it is impossible to guess before you know it.

My favourite one is italic. The whole italic alphabet is fine except lowercase h. Just one letter. Why? Because ℎ at U+210E was already there as the Planck constant symbol from physics.

Here is the fixed function. The change is small. Check the exception list first, then fall back to math.

const convert = (text, style) => {
  const { upper, lower } = OFFSETS[style];
  const gaps = EXCEPTIONS[style] ?? {};

  return [...text].map((ch) => {
    if (gaps[ch]) return gaps[ch];

    const code = ch.charCodeAt(0);
    if (ch >= "A" && ch <= "Z") return String.fromCodePoint(upper + code - 65);
    if (ch >= "a" && ch <= "z") return String.fromCodePoint(lower + code - 97);
    return ch;
  }).join("");
};

One thing I still cannot explain

Script lowercase e, g and o were all skipped, because ℯ, ℊ and ℴ already existed in the older block.

But script lowercase l was added to the new block at U+1D4C1, even though ℓ already existed at U+2113. Exactly the same situation, opposite decision.

If someone knows the reason behind that, please tell me in the comments. I looked and I could not find it.

The second thing that bit me

These characters live above U+FFFF. In JavaScript that means one visible character takes two slots inside the string.

This is why my code uses [...text] and not text.split(""). If you use split(""), it cuts these characters in half and you get broken output.

Before you write any code here, open your browser console and run this:

"𝐀".length

Whatever number you see there will tell you why string length cannot be trusted in this project.

The honest part

I have to say this, because I found it while researching and it changed how I think about my own project.

Unicode tells people not to do what I am doing. The Unicode Standard, chapter 22, says: "Characters from the Mathematical Alphanumeric symbols block should not be used to represent styling of nonmathematical text."

These characters were made to be different from normal letters on purpose. Using them as decoration is a misuse of the system.

And there is a real cost. Spammers use this exact trick to get past keyword filters, because a filter looking for a word will not match the same word written in math symbols. People have documented it in spam emails and even inside URLs.

So Fonti will ship with a warning next to the output. It will say clearly that this text is not real formatting, that it can break search and filters, and that it is a bad choice anywhere the text needs to be read by a machine.

One more thing I do not know yet: how screen readers announce these characters. I am not going to guess. I will test it properly and write about what I actually find.

Looking back at part 1

In part 1, I was stuck choosing between HTML, CSS, JavaScript, Python and React. I felt like I had to pick the right one before I could start.

This whole feature is plain JavaScript. A map, a loop, and some numbers. No framework, no library, no React.

The hard part was never the language. It was understanding the problem. I spent one hour writing the code and three days figuring out that fonts were not involved at all.

That is the thing I wish someone had told me in part 1.

Two questions

First: the script lowercase l inconsistency above. Does anyone know the story?

Second: are there other Unicode ranges with reserved holes like this, where offset math quietly produces invalid characters? Letterlike Symbols is the only overlap I found, but I doubt it is the only one that exists.

Next post: building the actual UI and the copy button, which turned out to have its own surprise.

References

I Decided to Build It. Then I Had to Actually Decide How.

Iris Khan — Sun, 30 Aug 2026 12:29:30 +0000

Last time, I decided to stop overthinking and start building Fontly, a free copy-paste font generator. Before writing a single line of the actual tool, I had to make a decision I thought would be quick and ended up being the thing I spent the most time on: the tech stack.

Here's how that thinking actually went.

Starting point: "just make it a static site"

My first instinct was the simplest possible option: a plain static site. No framework, no build step, just HTML/CSS/JS. For a small tool like this, that felt like the obvious beginner-friendly choice, and honestly, most "how to build your first project" advice points exactly there.

For a single page with one tool on it, that instinct isn't wrong. But the more I thought about where this project needed to go, the more that plan started to strain.

Where plain static started to break down

A few things I kept running into when I actually mapped out what Fontly needed, beyond just "the tool works":

This isn't going to stay one page: To be findable at all, a font generator needs supporting content: explainer pages, FAQs, maybe category-specific pages down the line, and hand-writing and hand-linking a growing pile of HTML files gets messy fast, with no structure keeping it consistent.
SEO isn't just meta tags: Clean semantic markup, sitemaps, fast load times, and consistent page structure all matter, and doing all of that by hand, correctly, on every new page is exactly the kind of repetitive work that's easy to get subtly wrong as a beginner.
Content and code kept wanting to be separate: The actual words on the page (headings, FAQ answers, descriptions) are things I want to be able to edit and expand without touching layout code every time.

That last point was the real turning point. I didn't need "a framework" for the sake of having one, I needed a way to manage content that wasn't tangled up with markup.

Why Astro specifically

Once I framed it as a content-management problem rather than an app-building problem, Astro made sense for a few specific reasons:

Content collections: Astro lets me define structured content (pages, FAQ entries, future blog posts) separately from how they're rendered, so adding a new page later means adding content, not rewriting HTML.
Ships minimal JavaScript by default: Unlike a full app framework, Astro renders to static HTML and only sends JavaScript for the parts that actually need interactivity, like the font-conversion tool itself. That matters for both load speed and SEO.
SEO fundamentals are built in, not bolted on: sitemap generation, clean output, and a structure that doesn't fight against good practices by default.
It's still simple underneath: The interactive logic is still plain TypeScript/JavaScript, Astro isn't replacing that, it's just handling the structure and content around it in a way that scales better than hand-written HTML would have.

The honest tradeoff

This wasn't a free upgrade. Astro means a build step, a bit of a learning curve, and more moving pieces than plain HTML/CSS/JS, genuinely more than I needed for day one. I went with it anyway because I was planning for where the project needed to go (more content, better SEO structure, room to grow) rather than just what got something on screen fastest.

Version control: Git and GitHub, before there was much to version

I set up Git and pushed to GitHub before I'd really written anything worth backing up. That felt slightly premature at the time, but a few reasons made it worth doing early instead of "later, once there's real code":

Cursor makes mistakes, and I make more: Since I'm leaning heavily on an AI coding assistant while still learning, I wanted the ability to undo a bad change without panicking, so I could commit often and roll back if needed.
It's the foundation everything else plugs into: Automatic deployment (more on that below) needs a repo to deploy from. Setting it up early meant that piece was just already there when I needed it, instead of being one more thing to configure later under pressure.
Habit-forming: As a beginner, if I don't build the habit of committing early, I don't build it at all. Starting on day one made it the default instead of an afterthought.

Nothing fancy here, just a repo, sensible commits, and a .gitignore so generated files and dependencies don't get tracked.

Hosting: why Cloudflare Pages specifically

For hosting, I wanted something that matched the "boring and reliable" philosophy of the rest of the stack. I picked Cloudflare Pages for a few concrete reasons:

Git-connected deploys: It builds and deploys straight from my GitHub repo: push to main, and the live site updates automatically. No manual uploads, no separate deploy step to remember.
Built for static/content sites like this one: Since Astro outputs mostly static files, Cloudflare Pages is a natural fit, it's designed around exactly that kind of output rather than needing a server running.
Fast by default, globally: Cloudflare's network means the site loads quickly regardless of where a visitor is, without me having to configure a CDN separately, which matters for both user experience and page-speed-related SEO signals.
Generous free tier: For a project at this stage, I don't want infrastructure cost to be something I'm thinking about yet. Cloudflare Pages' free tier is enough that I can put that concern aside entirely for now.

The combination, GitHub for version control and Cloudflare Pages for deployment, means my workflow is just: write code, commit, push, and the live site updates on its own a minute later. No manual steps in between to forget or mess up.

What's next

With that decision made, the next posts get into the actual build, starting with hosting and workflow decisions, then the tool itself.

Anyone else gone back and forth between "keep it simple" and "build it for where it's going"? Where do you usually land?

From Overthinking to Actually Building Something

Iris Khan — Fri, 28 Aug 2026 12:39:06 +0000

I'm Iris, new to web development. A little while back, 2 days ago probably, I wrote about not knowing what to learn first. The comments on that post were really encouraging, and they pushed me to stop overthinking it and just take action, start building something, even if it's not perfect, even if I don't know everything yet.

That "something" is Fontly, a free copy-paste font generator. It's not some big, ambitious project. It's small, and I'm just getting started. But it's mine, and it's real progress. This post is an update on where that decision has taken me so far: what I've built, what I've learned, and where it's headed.

The idea

If you've ever tried to make your Instagram bio, WhatsApp status, or a social post look a little different, you've probably searched for a "fancy text generator." Most of the ones out there are cluttered with ads, slow to load, or hide the good fonts behind a paywall.

That's the gap I'm trying to fill with Fontly, a clean, fast, completely free tool where you type your text once and instantly get a bunch of stylish font variations you can copy and paste anywhere. No sign-up, no clutter, no nonsense.

Where I'm at

I'm still early in my web dev journey, so this project is as much a learning exercise as it is a product. Right now I'm:

Finalizing the site's core functionality
Working through the basics of clean UI and page speed
Learning how SEO and discoverability actually work before launch, instead of scrambling after

Doing the planning work up front, thinking about structure, naming, and how people will actually find the tool, has honestly taught me more than the coding itself.

What's been challenging

A few things I didn't expect to spend so much time on:

Naming and branding: landing on "Fontly" took longer than I thought, and I wanted a name that would still make sense if I build more tools later
Thinking about SEO pre-launch: most guides assume your site is already live; figuring out what to do before that was a bit of trial and error
Balancing "keep it simple" with "make it actually good": as a beginner it's tempting to either overbuild or underbuild

- What's next

I'm continuing to build out Fontly and documenting the process as I go, the wins, the mistakes, all of it. If you're curious or want to follow along, I'll be posting updates here as things progress.

Would love to hear from anyone who's built a small tool/side-project as a beginner, what do you wish you'd known earlier?

I Have No Idea What to Learn First And Here's How I'm Deciding

Iris Khan — Thu, 27 Aug 2026 07:45:09 +0000

So I've decided I want to learn web development. Cool. Great. Except then I actually sat down to start and realized... I don't even know what to start with.

HTML? CSS? JavaScript? Python? React? Back-end stuff? People keep saying different things and every video has a different "you should start with THIS" opinion. It's honestly kind of overwhelming for someone who hasn't written a single line of real code yet.

So instead of learning anything, what I actually did was open like 15 tabs, watch parts of a bunch of videos, and close my laptop feeling more confused than when I started lol.

what I've looked at so far

Not much tbh. A couple YouTube videos comparing front-end and back-end (still not 100% sure I get the difference). One video tried explaining what JavaScript actually does on a page and I understood maybe half of it. And I've been scrolling posts here on DEV a lot, just reading how other people started. That part actually helped the most, not because anyone gave me THE answer, but because everyone started differently and that made me feel less stressed about "picking wrong."

how I'm picking

No real system, just vibes basically:

HTML/CSS feels the least scary to start with because you can actually see something change on the screen right away, and that feels good when you're this new to everything
if a lot of people keep saying "start here" for beginners, I figure there's probably something to it
and mostly I just need to pick SOMETHING and stop researching forever. I think the real mistake isn't choosing the "wrong" language first, it's never choosing anything at all

I'm not trying to get this decision perfect, I just want to actually start building stuff instead of just watching people build stuff.

so if you've been where I am right now, if you were starting completely over, what would YOU learn first?

not looking for a "correct" answer since i don't know if there even is one, just curious what actually worked for real people instead of another "top 10 languages to learn in 2026" article lol

10 Free Websites Every Web Developer Should Bookmark

Iris Khan — Wed, 29 Jul 2026 13:17:49 +0000

10 Free Websites Every Web Developer Should Bookmark
Whether you're just starting your web development journey or have been coding for years, the right tools can save you time and make your workflow much smoother.

Here are 10 free websites I think every web developer should know.

1. MDN Web Docs

The best place to learn HTML, CSS, and JavaScript. Clear explanations with reliable documentation.

2. CodePen

A great playground for testing HTML, CSS, and JavaScript without setting up a project.

3. Can I Use

Check browser compatibility before using modern CSS or JavaScript features.

4. GitHub

Perfect for hosting projects, collaborating with others, and exploring open-source code.

5. Regex101

Makes writing and debugging regular expressions much easier.

6. TinyPNG

Compress images to improve website loading speed while maintaining quality.

7. Excalidraw

A simple online whiteboard for sketching UI ideas and system designs.

8. DevDocs

A fast documentation browser that brings multiple programming docs together.

9. JSON Formatter

Useful when working with APIs and debugging JSON responses.

10. CSS-Tricks

An excellent resource for CSS tips, layout techniques, and front-end development articles.

Final Thoughts

These are some of the free resources I regularly use while learning and building web projects.

Do you have a favorite developer website that isn't on this list? I'd love to discover more—share it in the comments!