DEV Community: Iris Khan

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!