Quick Answer
To add text to an image free, open a browser tool, upload your photo, add a text box, type your words, then set the font, size, color, and position before you download. No signup or software is needed. Good tools work entirely on your device, so your image never leaves your browser.
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:
- Open the tool and upload your image. It stays in your browser, so nothing is sent to a server.
- Add a text box and type your words. Keep it short if it's a caption or headline.
- Pick a font and size. Bigger and bolder reads better on a busy photo.
- Set the color and, if you need it, a shadow or outline so the text pops off the background.
- Drag it into position, then download the finished image as PNG or JPG.
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.
Not sure if your text passes? A quick gut check: if you have to squint, so will your readers. When in doubt, add a subtle shadow. It costs nothing and rescues text on tricky backgrounds.
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.
What Common Mistakes Should You Avoid?
Do
- Keep captions short and scannable
- Add a shadow or band for contrast
- Size text to the image, not a fixed pixel
- Put text over calm areas of the photo
- Export as PNG to keep sharp edges
Don't
- Put light text on a light background
- Cover the main subject with words
- Cram in a full paragraph
- Use thin script fonts on busy shots
- Upload private photos to a server tool
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 colours 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 colour. 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-optimised 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 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, and the CanvasRenderingContext2D direction property (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-optimised PNGs respectively, so we cite both rather than the more flattering one alone.
Where can you learn more?