How to Add Text to Image Free: The Complete Guide

To add text to an image for free, upload your photo to a browser-based tool, add a text box, type your words, then set the font, size, color, and position before you download. That's the whole job, and it takes under a minute with no signup and nothing to install. Whether you're making a quote graphic, captioning a screenshot, labelling a product photo, or building a quick meme, the steps are the same. Below you'll find how to do it, how the tools work under the hood, and how to make sure your text is actually readable once it's on the picture.

The fastest way is our free text and watermark tool, which adds custom text to any image right in your browser. Here's the exact process.

How Do You Add Text to an Image for Free?

Five steps, about a minute, no account required:

1. Open the tool and upload your image. It stays in your browser, so nothing is sent to a server.
2. Add a text box and type your words. Keep it short if it's a caption or headline.
3. Pick a font and size. Bigger and bolder reads better on a busy photo.
4. Set the color and, if you need it, a shadow or outline so the text pops off the background.
5. Drag it into position, then download the finished image as PNG or JPG.

🅰️ Add Text to Image Free →

That's it. No Photoshop, no subscription, no watermark forced onto your download. If you also want to protect the photo from reuse while you're at it, our guide to watermarking photos free covers the tiled, semi-transparent approach that's hardest to crop off.

Why Would You Add Text to an Image?

Text turns a plain photo into something that communicates. A few of the most common reasons:

• Social media posts. Quote graphics, announcements, and captions that stay on the image when it's reshared.
• Memes and reactions. The classic top-and-bottom caption, or a line dropped over a reaction shot.
• Product and listing photos. Prices, sizes, or a "Sale" flash added straight onto the image for a marketplace.
• Labels and annotations. Pointing out a detail in a screenshot, or titling a diagram for a lesson or report.
• Branding. Your name, handle, or URL so every share carries a little credit back to you.

Because the words become part of the pixels, they travel with the image everywhere it goes, which is exactly what you want for a caption or a brand mark. If you're sizing these for a specific platform, our social media image size guide has the current dimensions.

Advertisement

How Do Browser Tools Add Text Without Uploading Your Photo?

This is the neat part, and it's why a good tool can promise your image never leaves your device. Browsers have a built-in drawing surface called the HTML Canvas. A tool loads your photo onto a canvas, then draws your text on top of it using a method called fillText. According to MDN Web Docs, fillText() "draws a text string at the specified coordinates, filling the string's characters with the current fillStyle." It also takes an optional maxWidth, and if you pass one the browser will tighten the kerning or shrink the font to make the text fit rather than letting it run off the edge. That's what a good tool is doing when a long caption quietly resizes itself. The MDN Canvas drawing-text tutorial walks through the same technique step by step.

Because all of this runs in JavaScript on the page you're already looking at, the photo is processed locally. Nothing gets uploaded, nothing is stored on a server, and the export you download is the canvas flattened back into a JPG or PNG. That's the difference between a private tool and one that quietly sends your images off to be processed. When you pick a tool, look for a clear statement that it works in your browser.

Does This Work for Non-English Text?

Mostly yes, and there are two specific ways it goes wrong. Both bite hardest with Chinese, Japanese, Korean, Thai, Tamil, Arabic, and Jawi, and both are easy to avoid once you know they exist.

The first is the font. Canvas draws using whatever font you name, and if that font has no character for what you typed, the browser goes hunting. The W3C CSS Fonts Module Level 4 describes the mechanism plainly: "A user agent iterates through the list of family names until it matches an available font that contains a glyph for the character to be rendered." If nothing installed on the device has that character, you get a row of empty rectangles where your words should be. The spec's own advice is to "append a generic font family as a last alternative for improved robustness," which is worth doing.

Here's why this matters more when you're putting text on a picture than when you're building a web page. On a page, a missing character is a temporary display bug: a visitor with the right font sees it correctly. On an image, you export the empty boxes. They become pixels, permanently, and they look identical to everyone who ever sees that file.

The second is direction. Canvas has a direction property, and MDN lists exactly three values for it: ltr, rtl, and inherit, with inherit as the default. Set it wrong for a right-to-left script and the characters come out in the wrong order. MDN's own example is blunt about the effect: "Hi!" drawn with direction set to rtl renders as "!Hi". Any tool worth using handles this, but it's the thing to check first if Arabic or Jawi text looks scrambled.

Four habits that catch both problems before you download:

• Preview with the real characters, not placeholder Latin. Type the actual caption. A tool that renders "Sample Text" perfectly tells you nothing about how it handles 中文 or ไทย.
• Empty boxes mean a missing font, not a broken tool. Switching to a font that covers your script fixes it. Noto families exist precisely for this and cover most writing systems.
• Check mixed-script captions on both halves. An English headline with a Chinese subtitle can render the first line beautifully and the second as rectangles, and it's easy to miss if you only glance at the top.
• Test on the device you'll publish from. Font availability is per device. A caption that looks right on your laptop can fall back to something else on your phone, because the phone doesn't have the same fonts installed.

Do that once and non-English text is no harder than English. Skip it and you find out after publishing, when the file is already out there.

How Do You Make the Text Readable?

Adding text is easy. Making it readable on a real photo is where most people slip. The single biggest factor is contrast between the text and whatever sits behind it. The W3C's WCAG 2.2 contrast guideline sets a bar you can actually aim at, and it explicitly covers "images of text," so a caption baked into a photo is held to the same standard as text on a page. Criterion 1.4.3, the AA level most people treat as the standard, asks for a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text. WCAG counts large as 18pt or 14pt bold, which works out to roughly 24px and 18.5px. Go up to the stricter AAA criterion, 1.4.6, and normal text needs 7 to 1, a level aimed at readers with vision around 20/80.

On a plain background that's easy. On a busy photo, use one of these tricks to hit that contrast:

• Add a shadow or outline. A dark drop shadow behind light text lifts it off almost any background.
• Drop a band behind the words. A semi-transparent dark or light rectangle gives the text a clean surface to sit on.
• Move the text. Place it over the calmest, most even part of the image, like open sky or a blurred area.
• Go bigger and bolder. Weight and size both help legibility, especially on small phone screens.

Which Font, Size, and Color Should You Use?

Font

Clean, bold sans-serif fonts read best over images because the thicker strokes hold up against a busy background. Save thin, decorative, or script fonts for calm backgrounds and large sizes. One font per image usually looks more intentional than mixing two.

Size

Scale to the image, not to a fixed number. A headline at roughly 5 to 8 percent of the image height reads well, which is about 55 to 85 pixels on a 1080-pixel-tall photo. Keep any body text at 24 pixels or more so nobody has to zoom in.

Color

White and black do most of the work because they contrast with the widest range of photos. White text with a soft dark shadow is the safest default. Pull a brand color from your palette only when it still clears the contrast bar against the image behind it.

Can You Use Any Font on an Image You'll Sell?

Not always, and this is the one thing in this guide that can actually cost you money. Two of the uses listed near the top, product and listing photos and branding, are commercial. The font you type in has a licence, and a good number of the ones marketed as "free" are free for personal use only.

The distinction is not about whether you paid. It's about what you're doing with the result. A caption on a holiday snap for your own feed is personal. A price flash on a product photo, a logo, a design going on merchandise, or anything attached to a business is commercial, even if the business is tiny and even if the image never earns anything directly.

The good news is that the safest option is also the easiest one. Every font in the Google Fonts library ships under a licence that permits free use commercially and personally, and most are under the SIL Open Font License. The official OFL FAQ is explicit about what that buys you. You can use the fonts in commercial work, including in logos, graphics, and manufactured products. And attribution is not required: the FAQ states that font authors "may appreciate being mentioned in your artwork's acknowledgements alongside the name of the font, possibly with a link to their website, but that is not required."

Two restrictions do exist, and neither touches what you're doing here.

• You can't sell the font files on their own. The stated intent is "to keep people from making money by simply redistributing the fonts." Bundling one inside a product is fine; selling the font as the product isn't.
• A modified version has to be renamed. If the original author declared a Reserved Font Name, your edited copy can't use it, and you can't reuse individual words from it either without written permission. That only applies if you're editing glyphs and passing the font on, not if you're typing with it.

SIL, who wrote the licence, sums up the permission as covering "any use, whether electronic or printed," and confirms bundling with applications including commercial ones.

So where's the trap? It's the free-font aggregator sites. Download a display face from one of the big font-download directories and there's a fair chance it's licensed for personal use only, with a commercial licence sold separately. The download is genuinely free. The right to put it on something you sell is not, and nothing in the download flow makes that obvious.

Three habits keep you clear, and they take about a minute total:

• Default to Google Fonts for anything commercial. Free, well-made, covers most scripts, and the licence question is already answered.
• If you downloaded it from somewhere else, read the licence file. It's usually a text file sitting in the same zip, and the phrase to search for is "personal use." If you can't find a licence at all, treat that as a no rather than a yes.
• Remember that system fonts aren't automatically free to redistribute either. Typing in a font that came with your operating system is fine, and the exported image is fine too, because you're shipping pixels rather than the font. That distinction is why adding text to an image is far simpler licensing-wise than embedding a font in a website.

That last point is the reassuring one, and it's worth ending on. Once your text is flattened into the picture, you're distributing an image, not a typeface. The licence question is about your right to use the font to make the thing, not about the file you send. Get the first part right and the rest looks after itself.

Can You Add Text to a Photo You Didn't Take?

It depends on the licence attached to the photo, and one common licence type says no in a way that catches people out constantly. The section above is about the font you type in. This one is about the picture underneath it, and honestly it's the more likely problem, because most people are far more careless about where an image came from than about which typeface they picked.

The easy cases are genuinely easy. Your own photo, no issue. Anything in the public domain or released under CC0, no issue. A stock image you bought, fine as long as the licence you bought covers what you're doing, which is worth actually reading if the end use is commercial.

The one that trips people is NoDerivatives. Creative Commons licences are built from condition letters, and per the Creative Commons FAQ, the ND condition "prohibits the sharing of adaptations of the material." Stamping a headline across a photo changes it. Whether your particular overlay legally amounts to an adaptation varies by jurisdiction, and CC's own FAQ doesn't settle the overlay question either way. That ambiguity is exactly the reason not to gamble on it. If the image you found is CC BY-ND or CC BY-NC-ND, save yourself the argument and find a different image.

Attribution is simpler than people fear. Creative Commons states that all of their licences require users to provide attribution to the creator when the material is used and shared. But they're deliberately relaxed about how, allowing flexibility in the way credit is given depending on the medium, means and context. So a credit line in your post caption or your page text usually does the job. You don't have to ruin your layout by branding the photographer's name across the middle of the image.

And one thing CC is refreshingly blunt about, which matters here more than you'd expect. Asked whether a creator can stop licensees using the work in other formats, their FAQ answers with a flat no. So converting that image to PNG or WebP after you've added your text, the sort of thing the export section below gets into, isn't the part to lose sleep over.

Three habits worth building:

• Record the licence when you download, not when you publish. You will not remember three weeks later, and the tab will be long closed.
• Treat business use like the font rules above. If money is anywhere near it, default to your own photos or images you've specifically licensed for commercial use.
• Screenshots and memes are their own question. What's permitted there turns on where you are and what you're doing, it varies a lot between countries, and nothing on this page is legal advice.

What If There's a Person in the Photo?

Then you have a second question, and it has nothing to do with the first one. The section above is about who owns the picture. This one is about who's in it. You can own a photo outright, shot it yourself, no licence involved at all, and still have a problem with the words you put across it.

Here's the part that surprises people, and it's the whole basis of everything else in this section.

A photo somebody can be recognized from is that person's personal data. Not a metaphor, the legal category. The UK's Information Commissioner's Office puts it in one line in its guidance on taking photographs: "If someone can be recognised from a photograph it's usually considered their personal data."

The Court of Justice of the European Union got there first and said it more formally. In Ryneš, decided 11 December 2014, the Court held that "the image of a person recorded by a camera constitutes personal data because it makes it possible to identify the person concerned". That case was about a home security camera, not a meme generator, but the principle it states is about images of people generally.

And the obvious objection has already been answered, which is the useful bit.

"It's just a personal thing, surely that's exempt." There is an exemption for purely personal or household activity, and in the same judgment the Court said it "must be narrowly construed". It then held that a camera pointed outwards from a private home across a public footpath fell outside the exemption entirely. Publishing a captioned photo to a public account is also pointing outwards. That's not a ruling about memes and nobody should pretend it is, but the direction of the reasoning is not ambiguous.

Now the part that belongs specifically on this page rather than on a general photography one.

The caption is the new risk. A photo shows what it shows. Text asserts. The moment you type words across a recognizable face, you can turn an image that said nothing in particular into a statement about a specific person, and that is a different category of problem from anything in the copyright section above. A photo of someone outside a shop is a photo of someone outside a shop. Add three words and it can become an accusation. The tool didn't make that claim. You did, and the picture now carries it.

This is also why "but it's obviously a joke" is a weaker defence than people assume. Obvious to you, in your feed, with your friends. The image travels without any of that.

So, practically:

• Identifiable plus published means you need a reason. The ICO's framing is that any use of personal data needs a valid reason, what it calls a lawful basis. Having the file is not the same as having a reason to publish it with your words on it.
• Ask, when asking is possible. For a colleague, a customer, a friend, a workshop attendee, it costs one message. Most awkwardness in this area comes from people who could easily have asked and didn't.
• Be much more careful with children. Schools and clubs run consent processes for exactly this reason, and a caption on a child's photo is the version of this that goes wrong loudly.
• Background is not the same as subject. A stranger walking past behind your product shot is a different situation from a stranger who is the point of the image. Text that draws attention to them moves them from one category to the other.
• Don't let the caption say more than you can stand behind. If the words make a factual claim about a person, you own that claim. Write it as what you saw, not as what you assume it means.
• Blurring the face is not the clean fix it looks like. The redaction section further down this guide covers why recovering obscured detail is more possible than most people expect. If the identification matters, crop them out or use a different photo.

Two honest limits on all of this. Rules about the person in a picture vary a great deal between countries, far more than copyright does, and some places have specific personality or image rights on top of data protection. And nothing here is legal advice. What this section is for is narrower and worth taking away on its own: the copyright question and the person question are separate, clearing the first tells you nothing about the second, and adding text is the step where a harmless photo quietly becomes a statement.

What Happens When You Put an Emoji in the Text?

You get your emoji. Specifically, you get the version your own device draws, frozen into the picture forever. And that's a stranger outcome than it sounds.

Emoji are characters, so the canvas renders them the way it renders any other character: with whatever font the device has for the job. On a Mac that's Apple's set, on Windows it's Microsoft's, on Android it's Google's. Same character, different artwork.

That isn't a bug anyone can fix, because nobody owns the pictures. The Unicode Consortium's own emoji FAQ is blunt about it: Unicode publishes charts showing "a representative glyph in a black and white text presentation," but is "not a designer nor purveyor of emoji images," and "has no control over the emoji images that platform vendors use." Vendors decide. You just inherit whichever one your machine happens to ship.

Normally that's invisible, because everyone sees their own set and nobody compares. Baking text into an image breaks that. Your iPhone's version of a face is now a picture, and every Android user who sees your post sees Apple's drawing rather than the one they know. Usually harmless, occasionally not, because the same character genuinely reads differently between platforms and a gesture or expression that lands one way in your preview can land another way in someone's head.

Two failure modes worth watching for before you export.

• The empty box. If your device doesn't have a glyph for the character, you get a blank rectangle, and the canvas will happily paint that rectangle into your image. Newer emoji are the usual culprits, since a device only knows the ones its font has been updated for. Unicode's emoji counts chart puts the total at 3,953 for version 17.0, and the set grows with each release, so "my phone knows it" and "this laptop knows it" aren't the same statement.
• The one that falls apart. Skin tones, family groups and profession emoji are built by joining several characters together, which is why People and Body alone accounts for 2,418 of that total. When the joining isn't supported, the pieces can render as separate emoji sitting side by side instead of the single figure you picked.

So preview at full size before you download, not in a small editor box. A tofu rectangle and a slightly-off face both look like nothing much at thumbnail size and like a mistake at full width.

One last thing, and it points straight at the next section. An emoji carries meaning, and once it's pixels that meaning is gone for anyone who can't see the image. If the emoji is doing real work in your caption rather than decoration, say so in words when you write the alt text.

Who Can't Read the Text You Just Added?

Anyone using a screen reader, unless you do one more thing. This is the part that gets skipped in every guide about putting text on images, including, until now, this one.

Here's what actually happened when you added that caption. The words stopped being words. They became pixels arranged in the shape of words, which your eye reads instantly and software cannot read at all. Nothing in the file says "this says 50% off this weekend." It just says: here are some colored dots.

The web has a rule for this. WCAG success criterion 1.1.1, Non-text Content, sits at Level A, the most basic conformance level there is, and it requires that all non-text content presented to the user has a text alternative that serves the equivalent purpose. The definition of non-text content explicitly includes images representing text. So a photo with a caption burned into it needs a text alternative, and it isn't optional under the standard.

The fix takes about five seconds. W3C's WAI images tutorial is specific about what to write for this case: for an image of text, the text alternative should contain the same words as in the image. Not a description of the image. The words themselves.

<img src="sale.jpg" alt="50% off this weekend only">

That's it. Same words, nothing clever. If the picture also carries meaning the words don't, add that too, but lead with the text.

Three things follow from that tutorial that are worth knowing:

• Decorative means empty, not missing. If the image adds nothing beyond the words already next to it, use alt="" so assistive technology skips it cleanly. Leaving the attribute off entirely is worse: a screen reader may fall back to reading the file name aloud, and nobody needs to hear "IMG underscore 4471 dot jpeg."
• W3C's own advice is to avoid images of text where you can. Their tutorial says to skip text in images unless it's genuinely necessary, logos being the classic exception. Real text over a CSS background does everything a baked-in caption does and stays selectable, translatable, and resizable.
• Match the words exactly. If you edit the caption in the image later and forget the alt attribute, you've now got two versions of your message in circulation and only one of them is right.

And a practical reason to care beyond the standard: baked-in text is invisible to more than screen readers. Nobody can copy it, a browser's translate feature walks straight past it, and it won't turn up in a page search. If the words matter enough to put on the picture, they probably matter enough to exist as text somewhere too.

None of this means don't add text to images. It's a guide about doing exactly that, and there are plenty of good reasons to, most of them in the second section. It means finish the job: add the words, then add the alt attribute, and the same message reaches everyone.

Will Search Engines Read the Text in Your Image?

Partly, and the honest answer is more interesting than the version you usually get. Search engines aren't blind to pictures. But the words you just baked in aren't treated as text on your page, and building anything important on the assumption that they are will cost you.

Google is fairly direct about how it works this out. Its image SEO documentation calls alt text "the most important attribute when it comes to providing more metadata for an image", and describes the process this way: "Google uses alt text along with computer vision algorithms and the contents of the page to understand the subject matter of the image."

Read that list again, because the order tells you something. Computer vision is in there, so this isn't a system that sees a blank rectangle. But it sits alongside two things you control completely, and those two are what you should be spending your effort on.

Here's what actually goes wrong. You make a graphic with your headline in it, drop it at the top of a post, and the page now has no heading. Not a small one, none. The words exist as pixels, so they can't be a heading element, they can't be pulled into a search result, and they can't be translated by a browser. You've written a headline that only humans looking directly at it can read.

Now the part that most guides miss, because it cuts the other way. On social platforms the image is the thing people actually see. A caption baked into the picture survives being reposted, screenshotted and stripped of its link, which is exactly why the format exists. That's a real advantage, not a compromise.

So the mistake isn't putting text in an image. It's letting the image be the only place the words exist. A usable rule:

• If the words need to be found, keep them in HTML. Headings, product names, prices, anything someone might search for. Put them on the page as real text and let the image carry the visual version.
• If the words need to survive a repost, put them in the image. Social captions, watermarked quotes, anything that travels without its original page attached.
• Usually you want both. Same message, two forms, with the alt text tying them together so nothing is only in one place.

That alt text is doing double duty, which is the neat part. The section above covers writing it for screen readers, and the exact same attribute is what Google calls its most important source of metadata for the image. One five-second habit, two entirely separate problems solved. If you're sizing graphics for feeds, our social media image sizes guide covers the dimensions, and choosing an image format covers what to export as.

What Common Mistakes Should You Avoid?

One more on export. If your text has crisp edges and flat color, PNG keeps them sharp, while heavy JPG compression can leave fuzzy halos around letters. Once it's exported, run the file through our image compressor to shrink it for the web without a visible drop in quality. For the full format rundown, see our guide to the best image format for websites.

And one caveat worth knowing before you bake anything important into a picture. The W3C's WCAG criterion 1.4.5, also Level AA, asks that where the technology allows it, you use real text rather than an image of text. The reason is simple: people can't alter how text looks inside an image. Someone who needs a larger size, a different font, more line spacing, or different colors can adjust real text through their browser or assistive tech, and can't touch a word once it's pixels. Screen readers can't read it either. So put your caption on the image for the visual punch, and also put the same words in the page text, the alt attribute, or the post caption. That way nobody has to be able to see the picture to get the message.

Will Your Text Survive Compression and Resizing?

This is the failure nobody sees coming. Your caption looks perfect in the editor at full size, then you post it and the words turn to mush. The image was fine. What changed is that something downscaled or recompressed it after you hit publish.

Two separate things do the damage, and they need different fixes.

Downscaling shrinks your text with everything else. A 60-pixel headline on a 1080-pixel-tall photo is comfortable. Push that same image into a 320-pixel feed thumbnail and the headline is now about 18 pixels, which is right at the edge of legible and well under the roughly 24px that WCAG treats as large text. Messaging apps and social feeds do this constantly, and they don't ask first. The fix is to check your text at the size people will actually see it, not the size you're editing at. Shrink the preview to thumbnail scale and see if you can still read it. If you can't, go bigger and cut words.

Compression eats the edges. JPG compression works by discarding detail in areas of sharp contrast, which is exactly what a letter is: hard edges against a different color. Push the quality down and you get fuzzy halos around type, worst on thin fonts and small sizes. WhatsApp in particular recompresses images hard, and our guide on compressing images for WhatsApp covers what actually survives that trip.

What holds up:

• Export text-heavy images as PNG, or better, lossless WebP. Both are lossless, so letters stay crisp. Use JPG only when the photo dominates and the text is small and incidental.
• Go bolder than feels necessary. Weight survives compression far better than size alone. A thin 60px font degrades worse than a bold 45px one.
• Compress once, deliberately. Export clean, then run it through our image compressor yourself so you control the quality setting instead of letting a platform pick it.
• Avoid text near the edges. Platforms crop to fit their own aspect ratios, and a caption sitting close to a border is the first thing to get sliced off.

That first bullet deserves a bit more, because the usual PNG-or-JPG choice is missing the better option. Lossless WebP gives you exactly what PNG gives you, letters with hard edges and no compression mush, at a smaller file. Google, who built the format, puts the numbers on its own WebP documentation: lossless WebP images are 26 percent smaller than PNGs, and lossy WebP is 25 to 34 percent smaller than comparable JPEG at the same SSIM quality. Their lossless compression study tested 12,000 PNG images pulled at random from the web and found WebP beat size-optimized PNG on over 99 percent of them. Note the two figures aren't the same comparison: 26 percent is against ordinary PNGs, while against PNGs already squeezed with ZopfliPNG the gap narrows to 23 percent. Still a win either way.

The old reason to avoid it was support, and that reason is gone. Google lists WebP as natively supported in Chrome, Safari, Firefox, Edge, and Opera. So for a caption graphic headed to the web, export lossless WebP and keep a PNG only if something in your workflow still insists on it. Our PNG vs JPG vs WebP comparison goes through the trade-offs properly.

There's a mirror version of this problem that catches people going the other way. Everything above is about your image getting smaller after you publish. But text can also go soft because you started too small, and no export setting fixes that afterwards.

Two habits prevent it. First, always add text to the largest copy of the photo you have, not to the version you already shrank for a previous post. Once detail is gone it's gone, and putting fresh text on a downscaled file just means your caption inherits a soft background. Second, remember most screens your work lands on aren't counting pixels the way you are. Mozilla's MDN documentation on devicePixelRatio puts it plainly: a value of 1 is a classic 96 DPI display, while "a value of 2 is expected for HiDPI/Retina displays," and modern phone screens "often yield a devicePixelRatio value greater than 2."

What that means in practice is simple. A graphic shown 400 pixels wide on a phone is being painted across 800 or 1200 actual pixels. Export it at exactly 400 and the browser stretches it to fill them, which is why perfectly good captions can look faintly fuzzy on a nice phone and crisp on an old monitor. So export at roughly twice the size you expect it to be displayed, then let the platform scale it down. Downscaling is kind to text. Upscaling never is.

Worth thinking about before you start, not after. Design the text for the smallest place it will appear, and it will look fine everywhere else.

What Else Changes When You Export the Image?

Two things you never asked it to change. Your photo can come out rotated, and all the invisible data attached to it quietly doesn't come along. Neither is a bug, and both surprise people.

Why a phone photo can come out sideways

When you turn your phone to take a portrait shot, the camera usually doesn't rotate the actual pixels. It saves them the way the sensor read them and writes a small orientation flag alongside, and your gallery app quietly obeys that flag when it shows you the picture.

Whether a canvas obeys it is a choice the tool makes. MDN's reference on createImageBitmap documents an imageOrientation option with three values. The default, from-image, means "Image oriented according to EXIF orientation metadata, if present." Set it to none and you get the image "oriented according to image encoding, ignoring any metadata about the orientation (such as EXIF metadata, that might be added to an image to indicate that the camera was turned sideways to capture the image in portrait mode)."

The fact that option exists at all is the useful bit. Orientation isn't automatic, it's decided. So the symptom to watch for is a photo that looks upright in your camera roll and lands sideways the moment it's in the editor. Your text then gets positioned against a rotated picture, and you only notice after downloading. Check the preview orientation before you place anything, and if it's wrong, fix the source first with our free rotate and flip tool and re-upload, rather than fighting it with text placement.

Why the file you download is a new file

MDN describes the canvas export method, toBlob, as creating "a Blob object representing the image contained in the canvas." That's the whole story in one line. You're not getting your original file with words painted onto it. You're getting a fresh encode of what's currently on the canvas. The only metadata MDN documents it writing is a resolution: "The created image will have a resolution of 96dpi for file formats that support encoding resolution metadata."

Which cuts three ways, and it's worth knowing all three.

• It's a privacy win, and a real one. Phone photos routinely carry GPS coordinates, a timestamp, and the device they were taken on. None of that survives the round trip. If you're posting a picture taken at home, at your child's school, or anywhere you'd rather not publish the coordinates of, that's a genuine benefit sitting alongside the local-processing point made earlier in this guide.
• It's a loss if you're a photographer. Creator and copyright fields go the same way as the GPS. If your workflow depends on embedded credit travelling with the file, re-add it after export, and keep the untouched original as your archive copy rather than replacing it with the captioned one.
• Watch it for print. A file exported this way declares 96dpi whatever the original said. For anything living on a screen that number is meaningless. For something going to a printer, set the size in your print software rather than trusting what the file claims.

The habit that covers all of it is simple: treat the captioned image as a derivative, not a replacement. Keep the original, export a copy with the text, and you get the privacy benefit without losing anything you might want later.

Can You Edit the Text After You Export?

Not in the finished file, no. And this is the one that gets people, usually about four minutes after they've closed the tab.

The moment you export a PNG or JPG, your text stops being text. It becomes pixels, indistinguishable from the pixels of the photo underneath it. There's no layer to click, no text box to reopen, and no way to fix a typo except painting over it or starting again. That's not a limitation of free browser tools specifically, it's what raster formats are. Even expensive desktop software gives you the same flat file once you flatten and export.

So the habit that saves you is boring and works. Keep the untouched original somewhere separate and never overwrite it. When the text needs changing, you reopen the clean photo and redo the overlay, which takes a minute rather than an afternoon of clone-stamping. Anyone who has tried to correct a date on a finished graphic without the original will tell you the same thing.

There's a better answer if you know in advance you'll be editing repeatedly. Use SVG instead. In an SVG, text stays text: the SVG text element holds real characters that stay selectable, searchable and editable in any text editor, and the W3C SVG 2 specification defines how they're laid out and rendered. Put your photo in as the background and your caption in a text element, and changing the wording later means editing one line.

That approach earns its keep in two situations. Localisation, where the same graphic needs the same layout in four languages and you'd rather not rebuild it four times. And anything with a number in it, since prices, dates and version labels are the things that change.

One catch worth knowing before you commit. SVG text renders using a font, which means it depends on that font being available wherever the file is opened, or being embedded in the file. If it isn't, the viewer substitutes something else and your careful spacing shifts. You can convert the text to outlines to lock the appearance, but then it stops being editable and you're back where you started. That's also where the licensing question from earlier comes back, because embedding a font is a different permission from using it to make a picture.

Can Anyone Recover Text You Blurred Out?

Usually yes. And the two techniques almost everyone reaches for are the two with published attacks against them.

This belongs in a guide about adding text because a large share of people who open one of these tools aren't writing a caption at all. They're covering something up. A name in a screenshot, an address on a parcel label, an order number, a phone number in a group chat. The tool has a blur brush or a pixelate option, it looks convincing on screen, and it feels like erasing.

It isn't erasing. It's averaging.

What the research actually did

Steven Hill, Zhimin Zhou, Lawrence Saul and Hovav Shacham studied exactly this scenario in Proceedings on Privacy Enhancing Technologies in 2016, and their opening line describes the habit precisely: "In many online communities, it is the norm to redact names and other sensitive text from posted screenshots. Sometimes solid bars are used; sometimes a blur or other image transform is used."

Their method borrows from speech recognition. They used hidden Markov models "in an analogous way to recover sequences of characters from images of redacted text", the same class of model that turns sounds into phonemes.

It worked on "both short and indefinitely long instances of redacted text". They tested it "against multiple typefaces, font sizes, grid sizes, pixel offsets, and levels of noise", and then decoded "numerous real-world examples of redacted text" that people had actually posted.

Their conclusion leaves no room to negotiate: "mosaicing and blurring, despite their widespread usage, are not viable approaches for text redaction."

The same year, Richard McPherson, Reza Shokri and Vitaly Shmatikov showed the problem isn't limited to text. In "Defeating Image Obfuscation with Deep Learning" they trained neural networks to "successfully identify faces and recognize objects and handwritten digits even if the images are protected" by mosaicing, "blurring (as used by YouTube)", or P3.

Both papers are from 2016. Everything about image recognition has improved enormously since then, and that improvement runs in exactly one direction.

Why the intuition is wrong

Pixelating and blurring feel like destruction because the result looks like mush to you. But both are predictable mathematical transforms. They don't remove the information, they smear it across neighbouring pixels, and the original values are still partly recoverable from those averages.

Text makes it worse, not better. There are only so many characters, in a small number of common typefaces, arranged in patterns a language model can anticipate. That is precisely the situation a statistical model is good at.

What to do instead

• Draw an opaque solid shape over it. Not a blur, not a mosaic, not a semi-transparent panel. A filled rectangle at full opacity, in a flat color.
• Crop it out if you can. Removing beats covering every time, and it leaves nothing to reconstruct.
• Then export, and check the exported file. The section above on what changes at export matters here: the download is a new flattened image with the pixels baked in. Some editors keep layers, so verify by reopening the file you're about to send, not the canvas you were working on.
• Watch opacity on anything you added deliberately too. A faint watermark or a low-opacity caption over a busy photo is still legible to software even where your eye struggles.

There's a wider point worth taking from this, and it connects back to the section on search engines. Text baked into a picture is not invisible to machines. Computer vision reads it. That's useful when you want your graphic understood, and it's the whole problem when the image contains a name or an address you assumed was just part of a photo.

So keep the two privacy questions separate. Browser-based tools that never upload your file, as described earlier, protect your image on the way in. Nothing about that protects the contents on the way out. Once you publish it, what's in the pixels is readable.

Do Content Credentials Survive the Edit?

No, and that's the system working rather than failing. If you've never heard of Content Credentials this section may not apply to you yet, but it's becoming harder to avoid, so here's the short version.

Content Credentials are provenance data attached to a file: who made it, with what, and what's been done to it since. The standard behind them comes from the Coalition for Content Provenance and Authenticity, which describes itself as providing "an open technical standard for publishers, creators and consumers to establish the origin and edits of digital content." This isn't a fringe project. Its steering committee lists Adobe, Amazon, BBC, Google, Meta, Microsoft, OpenAI, Publicis Groupe, Sony, TikTok and Truepic.

The mechanism explains why your caption breaks it. The C2PA FAQ describes Content Credentials as "tamper-evident, cryptographically signed data structures that travel with the asset." Tamper-evident is the operative word. Any modification, whether deliberate or accidental, "will break this cryptographic linkage, signalling tampering."

So look back at what the previous section established. Exporting from a browser canvas doesn't hand you your original file with words painted on. It hands you a fresh encode of whatever's on the canvas. A fresh file can't carry a signature that was calculated over a different one. The credential doesn't get lost by carelessness. It stops matching, which is exactly what it was built to do.

Worth knowing that the file isn't necessarily the only copy of that information. C2PA supports what it calls durable credentials, using soft bindings like invisible watermarking or fingerprinting, so a credential can sometimes be found again even after it's been stripped from the file itself. Sometimes. Don't plan around it.

Who actually needs to care. Be honest with yourself here, because the answer for most people is nobody.

• Captioning a meme, a sale graphic, or a photo for your group chat? This changes nothing for you. Carry on.
• Submitting to a stock library, a news desk, or a competition? Read their rules before you edit. Some now ask for files with provenance intact, and a captioned re-export won't satisfy that.
• Publishing where provenance is displayed? A growing number of platforms surface these credentials, and an image that arrives without them just looks like an image without them. Not an accusation, but not the signal you wanted either.

The fix is the same habit as the last section, which is convenient. Keep the untouched original somewhere safe and treat the captioned version as a copy you made for one purpose. If the provenance genuinely matters for a particular job, add your text in a tool that understands C2PA and writes a new signed record of the edit, rather than one that quietly hands you an anonymous new file.

And a caution while you're here. Uploading a file to a platform strips this stuff too, so it isn't unique to editing. Our guide on sending images through WhatsApp covers what re-encoding on upload does to a file, and the answer is roughly the same: what comes out the other side is a new file wearing your picture.

One reason to file this away even if it's irrelevant to you today: the signing is moving to the camera. The Content Authenticity Initiative points to the Google Pixel 10 shipping with C2PA credential support, which puts provenance in ordinary pockets rather than newsrooms, and to Sony's PXW-Z300 doing the same for professional video. The specification is moving too, now at version 2.4, dated April 2026.

What that changes for you is the starting point, not the mechanism. Up to now most photos you'd caption arrived unsigned, so there was nothing to break. As capture-side signing spreads, more of your source images will turn up with a credential already attached, and the moment you export a captioned copy from a browser canvas you'll be handing over a file that no longer matches it. Same behaviour as always. It just starts applying to holiday photos rather than only to press images.

What Else Do People Ask?

How do you add text to an image for free?

Open a free browser tool, upload your image, click to add a text box, type your words, then set the font, size, color, and position before you download. No signup or software is needed, and good tools do everything on your device so the photo never leaves your browser. The whole thing takes under a minute.

Can you add text to a photo without an app?

Yes. Modern browser tools add text using the built-in HTML Canvas API, so there's nothing to install. You upload the picture, type your text, style it, and download the result straight from the web page. It works the same on a phone or a laptop, and the image is processed locally rather than uploaded to a server.

What is the best font size for text on an image?

It depends on the image width, but a headline usually reads well at around 5 to 8 percent of the image height. On a 1080-pixel-tall photo that's roughly 55 to 85 pixels. Bump it up for social posts viewed on small phone screens, and keep body text large enough to read without zooming, which usually means at least 24 pixels.

How do you make text stand out on a busy photo?

Give the text strong contrast against whatever sits behind it. Add a drop shadow or outline, place a semi-transparent dark or light band behind the words, or move the text to a calmer part of the image. Aim for a contrast ratio of at least 4.5 to 1, the WCAG standard for readable text, so it stays legible for everyone.

Is it safe to add text to photos online?

It is if you use a tool that processes images in your browser rather than uploading them. Those tools do all the work on your own device, so your photo is never sent to or stored on a server, which keeps private pictures private. Check that the tool says it works locally, and avoid ones that require an account to download.

Sources: MDN Web Docs on the Canvas fillText() method, the Canvas drawing-text tutorial, the CanvasRenderingContext2D direction property, the createImageBitmap imageOrientation option and its from-image, flipY and none values, and the HTMLCanvasElement toBlob method, which MDN describes as creating a Blob representing the image contained in the canvas and documents as writing a 96dpi resolution (developer.mozilla.org); W3C WCAG 2.2 Understanding documents for criterion 1.4.3 contrast minimum and criterion 1.4.5 images of text (w3.org); W3C CSS Fonts Module Level 4 on the font-matching procedure and the advice to append a generic family for robustness (w3.org); Google WebP documentation on lossless and lossy size comparisons, and the lossless compression study of 12,000 randomly selected PNG images (developers.google.com); the official SIL Open Font License FAQ on commercial use in logos, graphics and manufactured products, on attribution not being required, on the bar against selling fonts standalone, and on Reserved Font Names for modified versions (openfontlicense.org), plus SIL's own font FAQ confirming the licence permits any use, electronic or printed (software.sil.org). All linked above. The 26 percent and 23 percent WebP figures are different comparisons, against ordinary PNGs and against ZopfliPNG-optimized PNGs respectively, so we cite both rather than the more flattering one alone.

Where can you learn more?

• How to Watermark Photos Free
• Social Media Image Sizes 2026
• Best Image Format for Websites in 2026