Golden Rules

Compression looks like a single slider or a single click, but underneath it there are two genuinely different approaches doing the shrinking, and understanding which one is at work explains almost every result you'll see out of a tool like this.

Lossy compression: throwing away what you won't notice

Lossy compression, the kind JPG and WEBP use, works by identifying information in an image that the human eye is bad at perceiving and discarding it. Subtle color gradients get simplified, fine high-frequency detail gets smoothed, and the result is a file that can be a fraction of the original size while still looking correct to a casual viewer. The catch is that this discarding is permanent — once that detail is gone, no amount of re-opening or re-saving brings it back, and compressing an already-compressed lossy file repeatedly compounds the loss each time.

The "quality ratio" or compression level you pick controls how aggressively this happens. A high quality setting throws away very little and shrinks the file modestly; a low quality setting throws away much more and shrinks it dramatically, at the cost of visible artifacts — blockiness around edges, smudged detail, color banding in skies and gradients.

Lossless compression: repacking without losing anything

Lossless compression, PNG's approach, works completely differently: it finds smarter, more efficient ways to store the exact same pixel data, the same way a ZIP file shrinks a text document without changing a single character inside it. Nothing is discarded, so you can compress and decompress as many times as you like with zero quality change. The tradeoff is that the size reduction is much smaller, because there's a hard mathematical limit to how much you can shrink data without throwing any of it away — especially for photographic images, which are full of the kind of fine, irregular detail that resists lossless repacking.

Why our Compress tool converts PNG to JPG

This is why Compress automatically converts PNG photos to JPG during compression: a PNG photograph run through lossless compression alone barely shrinks, but the same photo allowed to use lossy compression can shrink dramatically. For an actual photograph, this trade is almost always worth it — the quality difference is invisible at normal viewing sizes, and the file size difference is enormous. It's a different story for PNGs that aren't photographs (screenshots, logos, graphics with transparency or sharp text), which is why this conversion is specifically tuned for photo-like content rather than applied blindly to every PNG.

What actually happens when you move the quality slider

Internally, a lower quality setting increases how coarsely the image's color and detail information gets grouped and simplified before storage. Think of it like rounding numbers: rounding "quality 95" barely changes anything, while rounding "quality 40" changes things a lot more, but also takes up much less space to describe. There's no universal "correct" number — the right setting depends entirely on what the image will be used for, which is exactly what the next article gets into.

There's no single "best" compression setting — the right level depends entirely on where the image is going and what it needs to survive. Here's how to think about it by scenario.

Social media and messaging

Platforms like Instagram, WhatsApp, and most social feeds already re-compress every image you upload, often aggressively, regardless of what you send them. Uploading a huge, barely-compressed file here gains you nothing — the platform is going to compress it again on its end anyway. A moderate-to-high compression level keeps your upload fast and your original file size sane without giving up any quality you'd actually see after the platform's own processing.

Websites and online stores

For anything you're hosting yourself — a portfolio site, a blog, a product page — file size directly affects how fast your page loads, which affects both visitor experience and, for anything commercial, conversion rates and search ranking. Here it's worth leaning toward more aggressive compression, since web viewing rarely needs full print-level detail, and a page full of huge unoptimized images is one of the most common reasons sites feel sluggish.

Printing and professional use

This is the one place where you want to be conservative. Print reveals detail and artifacts that a screen simply doesn't, since it's viewed at higher effective resolution and often larger physical size. For anything going to a print shop, a gallery submission, or professional client delivery, use a light compression level or skip compression for that particular copy, and keep an uncompressed or lightly-compressed master file as your source of truth.

Archiving and long-term storage

If the goal is keeping a photo for years — family photos, an archive, anything you might want to revisit at full quality later — avoid heavy lossy compression on your only copy. Once detail is discarded, it can't be recovered, even if a later use case turns out to need it. A reasonable approach is keeping a higher-quality archival copy and generating separately-compressed versions on demand for whatever a specific use actually needs.

Email attachments and file size limits

Many email providers cap attachment size, commonly around 25MB total. If you're sending several photos, a stronger compression level gets you under that ceiling reliably. This is one of the few cases where the practical constraint (does it fit in the email at all) matters more than the visual difference between compression levels, so don't be afraid to compress harder than you would for other uses.

Image weight is one of the biggest, most fixable contributors to a slow website, and it's also one of the easiest to get wrong in either direction — too little compression and pages crawl, too much and photos look noticeably degraded. Here's how to land in the useful middle.

Why image size matters so much for speed

On most content-heavy pages, images make up the large majority of total page weight — far more than the HTML, CSS, or JavaScript combined. A visitor's page-load time, and search engines' assessment of it, is disproportionately affected by how heavy your images are, which means compressing them properly is often the single highest-leverage performance change available, ahead of most code-level optimizations.

Matching compression to how the image will actually be displayed

An image displayed at 400 pixels wide on a page doesn't need to be delivered as a 4000-pixel camera-original file compressed lightly — it needs far less detail than that to look sharp at its actual display size. Before worrying about compression level at all, make sure the image dimensions roughly match how large it will actually appear; compressing an oversized image is treating the symptom while leaving the bigger cause (unnecessary resolution) in place.

Choosing a format for the web

For photographic content, JPG or WEBP at a moderate-to-strong compression level is almost always the right call — visitors browsing a page don't need print-level fidelity, and the speed benefit of a smaller file is very real and very noticeable, especially on mobile connections. For flat-color graphics, screenshots, or anything with text and sharp edges, lossless PNG (left uncompressed by lossy methods) usually looks better and can even end up smaller than a heavily-artifacted lossy version of the same graphic.

The diminishing-returns point

Compression doesn't scale linearly with visual quality lost — the first chunk of compression from an uncompressed original removes an enormous amount of file size for almost no visible change, while pushing compression further and further into aggressive territory removes progressively less size for progressively more visible damage. In practice, most photos hit a sweet spot well before "maximum compression," and it's worth spot-checking a compressed image at its actual display size rather than assuming more compression is always better for speed.

Batch-processing a whole site's worth of images

If you're optimizing many images at once — a product catalog, a gallery, a blog's back-catalog of post images — apply a consistent compression level across similar content types rather than eyeballing each one individually. This keeps visual quality consistent across your site and makes it much faster to redo the process later if you change your mind about the setting, since you're not re-deciding case by case.

Compression is a genuinely useful tool, but it isn't automatically the right move for every image in every situation — knowing when to skip it is just as important as knowing how to use it.

Signs an image is a good candidate for compression

Large camera-original photos destined for the web, email, or messaging almost always benefit — they typically carry far more resolution and file weight than the destination needs. Any file that's hitting a hard size limit (an email attachment cap, an upload restriction, a form's file size ceiling) is an obvious candidate too, since compression is often the fastest way to get under the limit without cropping or resizing content out of the image.

Signs you should leave an image alone (or compress very lightly)

Graphics with text, sharp lines, or flat colors — screenshots, diagrams, logos, scanned documents — tend to compress poorly under lossy methods, since the compression artifacts show up as blurriness and color fringing exactly where the eye notices most: around edges and text. These are usually better served by PNG's lossless approach, or by skipping compression rather than fighting the artifacts.

Anything that's already been compressed once shouldn't casually be compressed again "for good measure." Recompressing a JPG that's already lossy-compressed doesn't meaningfully shrink it further in most cases, and can introduce a second round of quality loss on top of the first, stacking artifacts rather than removing them.

The master-copy habit

A simple rule that avoids most regret: keep one high-quality (or uncompressed) master copy of anything you might reuse later, and generate compressed versions from that master as needed for each specific use, rather than overwriting your only copy with a compressed one. Storage is cheap; recreating a lost original is not possible once it's gone.

Judging by the destination, not by habit

The right question isn't "should I compress this image" in the abstract, it's "what does the place this image is going actually need." A photo bound for a text message needs almost none of its original detail; a photo bound for a large printed banner needs nearly all of it. Let the destination set the bar, rather than applying the same compression level out of habit to everything that passes through your workflow.

Most compression complaints trace back to a small set of repeatable mistakes. Here's what to watch for.

Compressing the same file over and over

Every lossy compression pass throws away a little more detail, and that loss compounds with each additional pass — a file that's been compressed, re-opened, edited, and re-compressed several times will look noticeably worse than one compressed once from a clean original. Always compress from the original or an uncompressed master, not from a previously-compressed copy.

Overwriting your only copy

Compressing in place and deleting the original is the single most common way people lose access to full quality permanently. Once a lossy compression pass has discarded detail, there's no way to get it back — keep the original somewhere safe until you're certain you won't need it at higher quality later.

Compressing graphics as if they were photos

Screenshots, logos, and text-heavy graphics don't respond well to the same lossy compression that works great on photographs — the sharp edges and flat colors that make these images what they are turn into visible smudging and color fringing under lossy compression. These are typically better handled with lossless formats, or a much lighter compression touch than you'd use on a photo.

Choosing a compression level without checking the result

It's tempting to pick "maximum compression" for the smallest possible file and move on, but that setting often introduces artifacts that are obviously visible once you actually look at the output at real size. A quick check of the compressed result — at the size it'll actually be viewed — takes seconds and prevents sending or publishing something that looks noticeably worse than intended.

Ignoring the destination's own compression

Uploading a barely-compressed, huge file to a platform that's going to compress it anyway (most social media and messaging apps) wastes upload time and bandwidth for no visual benefit, since the platform's own processing determines much of the final quality regardless of what you sent. Match your compression effort to what the destination will actually preserve, not to an assumption that "more original quality in equals more final quality out."

Combine's whole job is deceptively simple — take several files and merge them into one PDF — but the detail that trips people up most often isn't the merging itself, it's making sure the pages land in the order you actually intended.

How Combine determines page order

Combine merges your files in the order they appear in your selection — the order you picked them in the file browser, or the order they were dropped in, from top to bottom. It doesn't try to guess a "correct" order based on file names, dates, or content, because there isn't a universal rule for what order you want; it simply respects the sequence you gave it. That means the responsibility for correct ordering sits entirely with how you select or arrange files before hitting combine.

Why file names can be deceiving

A common assumption is that files will merge in alphabetical or numerical order automatically. If your operating system's file picker happens to list files that way, and you select them by dragging across the whole list, that's often what you'll get — but it's a side effect of the file picker's display order, not a guarantee. The moment you select files individually with the mouse, out of sequence, or drag them in one at a time, the merge order follows your clicks, not the file names.

A reliable pre-check before combining

Before clicking combine, look at the preview list Combine shows you — this reflects the actual order the merge will use. If something's out of place, remove it and re-add it in the right position, or reorder your selection before uploading in the first place. This thirty-second check is far faster than downloading a merged PDF, discovering page 4 is actually supposed to be page 2, and starting over.

Naming files to make ordering foolproof

If you're regularly merging multi-file sets — scanned pages, multi-part reports, sequential chapters — a simple habit that removes ordering guesswork entirely is prefixing file names with numbers before combining: 01-cover.pdf, 02-resume.pdf, 03-portfolio.pdf. Selecting all of them at once in a file browser will then naturally follow that numeric order, and you get correct sequencing without needing to manually arrange anything in Combine itself.

Job and internship applications are one of the most common reasons people reach for a PDF-merging tool, and getting the structure right can genuinely affect how your application is received.

Why employers prefer one PDF over several attachments

A hiring manager or recruiter often reviews dozens or hundreds of applications, frequently on a phone or by skimming quickly between meetings. An application that arrives as three or four separate attachments (cover letter, resume, portfolio, references) forces them to open and juggle multiple files just to get the full picture, and it's easy for one attachment to be missed, misfiled, or simply not opened at all. A single, well-ordered PDF removes that friction entirely — one click opens everything, in the order you intended it to be read.

The order that works for most applications

A sensible default sequence is: cover letter first (it's the shortest and sets context), resume second (the core of what most reviewers actually want), then supporting material — portfolio samples, certificates, references — last. This mirrors how most people naturally want to read an application: context, then substance, then supporting evidence, rather than starting with a portfolio before knowing what job you're even applying for.

Combining files that started in different formats

It's common for a cover letter to exist as a Word-exported PDF, a resume as a separate PDF, and portfolio samples as image files (photos of physical work, screenshots of digital projects, scanned certificates). If your portfolio pieces are images rather than PDFs, convert them to PDF first using the Convert tool's PDF output, which turns a batch of images into one PDF with each image as its own page — then combine that resulting PDF with your cover letter and resume PDFs in the order you want them to appear.

Keeping file size reasonable

Portfolio images, especially camera photos of physical work or high-resolution screenshots, can be unnecessarily large. If your combined application PDF ends up huge, it's worth compressing the source images before converting them to PDF and merging, rather than after — a large, slow-to-open attachment is a small but real point of friction for anyone reviewing it under time pressure.

Double-checking before you submit

Once merged, open the final PDF and scroll through it once, start to finish. This catches out-of-order pages, an accidentally-included draft version, or a portfolio image that didn't convert the way you expected — the kind of small mistake that's invisible until you actually look, and considerably more embarrassing to discover after an employer has already opened it.

Scanned paperwork — contracts, forms, ID documents, multi-page letters — brings its own particular ordering challenges, mostly because of how scanning itself tends to happen.

Why scanned pages go out of order more often than other files

Many scanners and scanning apps save each page as a separate file with a generic, auto-generated name (scan001.pdf, IMG_2024.jpg, and so on), sometimes numbered by the order pages were physically fed into the scanner and sometimes not. If you scanned a stack of pages out of physical order, or a multi-function printer numbered them unexpectedly, the file names won't reliably reflect the document's true reading order — which means selecting files "in name order" can silently produce a merged document with pages out of sequence.

The safest approach: check content, not just file names

Before merging, glance at each scanned page's actual content (Combine's preview thumbnails make this quick) rather than trusting the file name alone. It only takes a few seconds to confirm page one is really the top of the document and page two follows it logically, but it's the single most reliable way to avoid submitting a scrambled document to a bank, government office, or landlord — places where an out-of-order document can cause real delays.

Mixed scans: some pages photographed, some scanned

It's common to have a proper scan for most pages and a phone photo for one or two (a page that didn't fit on the scanner bed, or was scanned later as an afterthought). Combine handles images and PDFs interchangeably, so this isn't a problem technically — but visually, a photographed page often looks different in lighting and framing from a true scan. If consistency matters for the document's appearance, it's worth re-scanning the odd-one-out page properly rather than mixing formats, though this is a cosmetic concern rather than a functional one.

Multi-page contracts and signature pages

For contracts or forms with a signature page, that page needs to end up in the exact right position relative to the rest of the document, since a signature page merged into the wrong slot can make a legal document look invalid or incomplete. Treat these as a hard case for the preview-before-combining check above — this is exactly the situation where a five-second look at the ordered preview list saves you from a document that has to be re-signed and re-sent.

Merging everything into one PDF isn't always the better choice — sometimes separate files genuinely serve the recipient better, and it's worth knowing which situation you're in.

When combining is clearly the right call

Anything meant to be read in a specific sequence — a multi-page application, a scanned contract, a report with an introduction followed by supporting data — benefits enormously from being one file, since it guarantees the reader encounters everything in the order you intended and can't accidentally open pages out of sequence or skip something. Anywhere a form or platform explicitly asks for "a single PDF" is also an easy call: combine and submit exactly what's requested.

When separate files serve the recipient better

If a recipient needs to act on documents independently — say, forwarding just the invoice to accounting while keeping the delivery note for their own records — merging those into one file makes their job harder, not easier, since they'd have to extract or reprint just the piece they need. Similarly, if you're sending several genuinely unrelated documents to someone who'll file them in different places, separate files let them handle each one on its own terms rather than fighting with a bundled PDF.

Large collections of reference material

If you're sending a large batch of loosely-related images or documents that aren't meant to be read in sequence — a big batch of reference photos, for instance — a ZIP archive of separate files can actually be more useful than one giant PDF, since the recipient can browse and open individual items rather than scrolling through a single enormous document to find one photo.

A quick way to decide

Ask whether the files represent one coherent thing that should be read start to finish (combine it), or several independent things that happen to be sent together (keep them separate, or ZIP them). Most job applications, contracts, and scanned multi-page documents fall clearly into the first category; most reference material, batch deliverables, and independently-actionable documents fall into the second.

Combine is a simple tool, but a handful of avoidable mistakes account for most of the frustration people run into with it.

Trusting file names for order instead of checking the preview

As covered in the ordering articles above, file names don't always reflect the order you actually want — especially for scans and downloads with auto-generated names. Always glance at the preview list before combining rather than assuming the selection order matched your intention.

Mixing unrelated documents into one file "for convenience"

Combining several unrelated documents just to have fewer files to manage often backfires — the recipient now has to open a large merged file and scroll to find the one section they actually need, rather than opening the specific file directly. Reserve combining for documents that genuinely belong together as one coherent read.

Not checking the final file before sending it

A merged PDF should be opened and skimmed once before it goes anywhere important. This is the step that catches an out-of-order page, an accidentally duplicated document, or a page that didn't render the way you expected — problems that are trivial to fix before sending and considerably more awkward to explain after the fact.

Forgetting to convert images before merging them with PDFs

If you have loose images you want included in the same merged document as existing PDFs, remember that Combine merges files as provided — for the smoothest result, make sure images are already in the format and order you want, since fixing an image's orientation or content after it's already part of a merged PDF is far more of a hassle than fixing it beforehand.

Sending an unnecessarily huge merged file

Merging several already-large PDFs or high-resolution scanned images produces a combined file that inherits all of their weight — if the result is unexpectedly huge, it's worth compressing the source images before merging rather than after, since a slow-to-open, oversized PDF is a common source of complaints from recipients on slower connections or older devices.

Every photo your phone or camera takes carries far more than the picture itself. Tucked inside the file is a block of metadata — EXIF data — that quietly records a surprising amount of detail about when, where, and how the photo was taken.

Location: the big one

If location services were enabled when the photo was taken, most phones embed the exact GPS coordinates of where the shot happened, often precise to within a few meters. Anyone who opens the original file in the right viewer, or runs it through a metadata reader, can plot that location on a map — which means a photo taken at home, at a workplace, or at a child's school can reveal exactly where that place is, without you ever writing the address anywhere.

Device details

EXIF typically includes the exact make and model of the camera or phone that took the picture, sometimes down to the specific software version. On its own this seems harmless, but combined with other metadata it adds another identifying detail to a photo, and in some contexts (marketplace listings, anonymous accounts) it can be one more thread that ties a photo back to a specific person's known devices.

Timestamps

The exact date and time the photo was taken is recorded down to the second, which is more precise than most people realize — a photo posted "casually" can reveal exactly when someone was at a particular location, which becomes relevant for anyone thinking about their routine or whereabouts being pieced together from a pattern of posted photos over time.

Camera settings and, sometimes, more

Technical details like aperture, shutter speed, and ISO are also stored, which matter to photographers reviewing their own shooting but are otherwise not privacy-sensitive on their own. Some devices and editing apps additionally embed a thumbnail preview, software/editing history, or even a copyright or author name field, depending on settings — the exact fields present vary by device and app, but the location and timestamp data are the two that carry the most real privacy weight.

Why this matters even for "unimportant" photos

Most individual photos feel low-stakes on their own, but metadata compounds: a stranger with access to several of your photos' location data can map out a pattern of places you frequent — home, workplace, gym, a child's school — that no single photo would reveal by itself. This is exactly the gap Cleanly exists to close: stripping this metadata before a photo leaves your device removes that entire layer of hidden information, while leaving the visible image itself completely unchanged.

Two of the most common situations where EXIF data quietly causes real problems are selling items online and posting photos publicly — both involve photos going to strangers, which is exactly when hidden metadata matters most.

Selling on marketplaces

Photos of items for sale — furniture, electronics, a car, a home for rent — are almost always taken at the seller's home or workplace. Left untouched, these photos can hand a buyer your exact address before you've ever met them or agreed to anything, simply by opening the image's metadata. This is a real, documented way people have had their home location exposed to strangers who had no prior legitimate reason to know it. Running listing photos through Cleanly before uploading removes this risk entirely, with zero visible difference to the buyer.

Posting to social media and forums

Most major social platforms strip metadata automatically on upload, which is good news, but not every platform does, and forwarded or downloaded copies of your photo (screenshots, saves, reposts) don't reliably go through that same stripping process. If a photo is ever downloaded from where you posted it and reshared elsewhere, any metadata that survived the original upload travels along with it. Stripping metadata before you post at all is the only way to guarantee it's never present anywhere in the chain.

A simple pre-posting habit

Before uploading photos anywhere they'll be visible to people you don't know personally — a marketplace listing, a public social post, a forum, a dating profile — run them through Cleanly first. It takes seconds, works on a whole batch of photos at once, and produces visually identical copies with none of the hidden data. Making this a default step, rather than something you only remember for "sensitive" photos, means you're never caught out by a photo you didn't think twice about.

What stripping doesn't change

It's worth being clear about what Cleanly does and doesn't do: it removes hidden metadata from the file, but it can't remove information that's visible in the image itself — a street sign in the background, a visible house number, a reflection showing your location. Metadata stripping handles the invisible layer; anything visible in the photo itself is a separate consideration you still need to check with your own eyes before posting.

Photographers have a slightly different relationship with metadata than casual phone users — some of it is genuinely useful to keep for their own records, which makes "strip everything, always" not quite the right instinct.

Why photographers might want to keep some metadata locally

Camera settings — aperture, shutter speed, ISO, focal length — are valuable when reviewing your own shots later: understanding which settings produced a shot you liked helps you replicate it. For your own working copies, kept privately, there's no reason to strip this information, since it's genuinely useful reference data that doesn't carry privacy risk as long as the files stay with you.

Why delivered or published copies are a different matter

The moment a photo is delivered to a client, published on a portfolio site, or posted publicly, the calculation changes — location data especially has no business being in a client-facing or public file, since it can reveal shoot locations that were meant to stay private (a client's home for a family shoot, a private venue, a studio's exact address if that's not meant to be public). Cleanly is meant for exactly this step: run final, outward-facing exports through it before delivery or publishing, while keeping your own working files with full metadata intact for your own reference.

No quality loss, ever

A common (and reasonable) worry is that stripping metadata might somehow affect image quality — it doesn't. Metadata is a separate block of text-like information stored alongside the pixel data, not mixed into it, so removing it has zero effect on resolution, color, or sharpness. Cleanly's output is pixel-for-pixel the same photo, just without the hidden data traveling alongside it.

Building it into a delivery workflow

For photographers who deliver galleries or export batches regularly, the simplest approach is treating metadata stripping as the last step before export, applied to the whole batch at once rather than photo by photo. This way it becomes a routine part of finishing a job, similar to a final quality check, rather than something that has to be remembered separately for each client or each platform a gallery gets shared to.

Protecting clients as much as yourself

It's worth remembering that the location and device data at risk in a client's photos is often about the client's life, not yours — a family portrait session shot at their home, a couple's engagement photos at a meaningful private location. Stripping metadata before delivery protects your clients' privacy as much as your own professional reputation for handling their images carefully.

Not every photo carries the same privacy stakes — knowing which situations genuinely call for metadata stripping helps you focus the habit where it actually matters most.

Photos taken at home or a workplace

Any photo taken inside or immediately around your home or workplace — including marketplace listing photos, "working from home" shots, or casual pics taken in your living room — carries location metadata that maps directly to a place you spend regular, predictable time. This is consistently the highest-stakes category, since it's the location most valuable for someone to know and the one most people don't think to protect.

Photos involving children

Photos of children — at school, at a regular activity, in a neighborhood — carry an extra layer of risk if location metadata survives, since it can reveal where a child predictably is at recurring times. Many parents already think carefully about what's visible in a photo before posting; the same care is worth extending to what's invisible in the metadata.

Anything going to a stranger before trust is established

Marketplace buyers, online dating matches, and other contexts where you're sharing photos with someone you haven't personally vetted are exactly the situations where you don't want to hand over more information than you intended. A listing photo or profile photo is the clearest example: the recipient has no established relationship with you yet, and stripped metadata means the photo reveals only what's visible in it, nothing more.

When it matters less

Metadata stripping is far less critical for photos shared privately with people you already know and trust — sending a photo directly to a family member or close friend through a private channel doesn't carry the same exposure risk as posting publicly or sending to a stranger. It's not that metadata is ever actively beneficial to leave in for privacy purposes, just that the practical urgency scales with how public or untrusted the recipient is.

A reasonable default

Given how quick and lossless the process is, there's little downside to making metadata stripping a default habit for anything leaving your immediate, trusted circle — it costs you nothing in quality or effort, and it means you're never relying on remembering to do it selectively for the specific photo that turns out to matter.

Most photo-privacy problems come from a handful of habits that feel harmless in the moment. Here's what to watch for.

Assuming the platform already handles it

It's true that many major social platforms strip metadata automatically on upload, but not all platforms do, and forwarded copies, downloads, and reshares don't reliably pass back through that same stripping. Relying on "the platform probably handles it" is a gamble; stripping metadata yourself before posting removes the uncertainty entirely.

Only thinking about what's visible in the photo

People often carefully check a photo for visible details — no sensitive documents in the background, no readable street signs — while forgetting that the invisible metadata can leak the exact same kind of information (specifically, location) even when the image itself looks perfectly safe. Checking the visible content and stripping the metadata are two separate, both-necessary steps.

Selling items with untouched listing photos

Marketplace listings are one of the most common real-world sources of accidental location exposure, since sellers photograph items exactly where they live and upload the photos as-is. This is one of the clearest, highest-value cases for stripping metadata before posting, since the risk (revealing your home address to strangers) is concrete and the fix takes seconds.

Forgetting about old, already-posted photos

Metadata stripping only protects photos you strip before sharing — it doesn't retroactively fix photos already posted somewhere with metadata intact. If you're concerned about past posts, the fix is going back to those specific photos, removing and replacing them with stripped versions if the platform allows it, rather than assuming the habit going forward covers everything already out there.

Treating it as an all-or-nothing, occasional task

Waiting to strip metadata only for photos that "feel sensitive" means relying on your own judgment call every single time, which is exactly the kind of habit that eventually misses one. Building metadata stripping into your default routine for anything leaving a trusted circle removes the judgment call entirely — it's applied consistently instead of selectively.

Everything above is about EXIF data embedded in photos — GPS, camera model, timestamps. SVG files don't have EXIF at all, since they're not photos; they're XML text describing shapes. But design tools embed their own kind of hidden metadata into an SVG, and Cleanly detects and strips that too when you drop one in.

What design tools embed in an SVG

Illustrator, Inkscape, Sketch, and Figma all write more into the file than the shapes you drew: an embedded <metadata>/RDF block (sometimes including authorship and licensing info via Dublin Core tags), editor-specific namespaced attributes (Inkscape's sodipodi: tags are the most common), and plain XML comments left by the export process. None of it is visible when the SVG renders, but all of it ships with the file to anyone you send it to.

Why this matters for sharing

The same reasoning that applies to a photo's GPS tag applies here: metadata you didn't consciously add is still metadata that goes out the door with the file. An icon or logo exported for a client, a marketplace listing, or a public repo can carry along software version info or authorship attribution you never meant to publish. Stripping it before sharing is the same "costs nothing, prevents a surprise" habit as stripping EXIF from a photo.

What Cleanly shows you before stripping

Just like it lists the GPS, camera, and date tags found in a photo, Cleanly scans a dropped SVG and shows exactly what it found — embedded metadata, editor authoring data, or comments — so you can see what's actually in the file before removing it, rather than stripping blind.

Lossless, not lossy

Unlike photo compression, this isn't a quality tradeoff. The cleanup only removes cruft the browser never rendered in the first place — the shapes, colors, and structure your design tool created are left completely untouched, so the cleaned file looks pixel-identical and can still be opened and edited in a vector editor afterward.

A PDF page isn't a text document you can just click into and type — it's closer to a printed sheet, a fixed picture of text and graphics laid out at exact positions. Understanding that distinction explains both what Context does and why it works the way it does.

The page is a picture, not a document

Most PDFs (anything that isn't specifically built as a fillable form) have no concept of "empty space you can type into." What you see as a line, a box, or a blank field is really just ink placed at fixed coordinates — there's no underlying text field waiting to receive your input, the way there is in a Word document or a web form. When Context lets you "add text" to a PDF, it isn't finding a hidden field and filling it in; it's placing a brand-new, independent layer of text on top of the existing page, positioned wherever you drag it.

Overlaying vs. editing

This overlay approach is the same one used by essentially every PDF annotation tool, not just this one — genuinely editing the original text of a PDF (changing a sentence that's already printed on the page) requires specialized software and often isn't possible at all if the original file didn't preserve editable text layers. What Context does instead is simpler and far more broadly useful: it adds a new, separate piece of text that sits visually on top of the page, which is exactly what you want for captions, notes, initials, or filling in a blank line on a form.

Points, not pixels

PDF pages measure position in points (1/72 of an inch), not the on-screen pixels you're dragging with your finger or cursor. Context handles that conversion for you — what you see on screen, at whatever zoom level you're viewing the page at, always maps back to the correct fixed position in the actual PDF, so a text box you place at the top of a page stays at the top of the page regardless of what device or zoom level someone else opens it at later.

What happens when you download

When you hit Download, every text box you've placed gets permanently drawn onto the PDF's pages — colors, bold/italic/underline styling, exact position and size all included — producing a single, ordinary PDF file. There's no special "Context format" and nothing separate to keep track of: the file that comes out opens and prints identically to any other PDF, in any PDF reader, on any device.

The right text size and position depends entirely on what kind of document you're marking up and who's going to read it next. Here's how to think about it by scenario.

Matching the document's existing text

The single biggest thing that makes an added line look intentional rather than pasted-on is matching its size to whatever's already printed nearby. If the form's labels are printed at roughly 11–12pt, adding your answer at 24pt makes it look like it doesn't belong, even if the position is perfect. Zoom in on the surrounding printed text first, get a rough sense of its scale, and pick a nearby size — Context remembers the last size you used, so once you've matched it once, every following box starts from the same size automatically.

Staying inside the lines — literally

Blank lines and boxes on forms are usually sized for a specific amount of text at a specific size. Before typing a long answer into a short line, consider whether it needs to shrink slightly to fit, since text that overflows past the end of a printed line looks like a mistake to whoever reads the finished document next, even though nothing is technically broken.

Choosing a color that reads as "added," not "hidden"

Black text is usually the safest default, since it matches how most forms and documents are already printed and doesn't call attention to itself as an addition. Colored text is genuinely useful for notes, corrections, or anything you specifically want to stand out from the original content — just make sure the color you pick has real contrast against the page behind it; light colors like yellow are easy to lose against a white page.

Leaving margin for the unexpected

Placing text right at the very edge of a page risks it getting clipped if the document is later printed on a slightly different paper size or margin setting than expected. Leaving a small buffer between your text and the page edge — and between your text and any nearby printed content — keeps the result looking clean regardless of how it's eventually printed or viewed.

Print, sign, scan, and email back is still how a lot of paperwork gets handled — and it's almost always unnecessary. Here's how to skip it using nothing but a browser.

Replacing the print-sign-scan loop

If a form only needs a name, a date, a few short answers, and a mark where a signature goes, there's rarely a real reason to involve a printer or scanner at all. Open the PDF directly in Context, place a text box on each blank line, type your answer, and download — the entire round trip that used to require paper now takes place entirely on screen, and the result is a cleaner, more legible PDF than a scanned paper copy usually is anyway.

Typed signatures and initials

Typing your name in a script-like or handwriting-style approach onto a signature line is common practice for a large share of everyday paperwork — internal company forms, informal agreements, acknowledgment forms, and similar low-stakes documents. It's worth being clear-eyed about one thing though: a typed name is not the same as a legally recognized electronic signature under laws like eIDAS or the U.S. ESIGN Act, which generally require specific consent and verification steps that a simple typed overlay doesn't provide. For contracts, legal filings, or anything where signature validity actually matters, use a dedicated e-signature service instead — Context is the right tool for informal paperwork, not a replacement for one.

Lining answers up with printed labels

Most forms print a label ("Name:", "Date:") followed by a blank line or box for the answer. Drag your text box so it sits just above the line rather than on top of it — text placed directly on a printed line becomes hard to read once both overlap, while text floating just above stays clearly legible and still reads as "the answer to that label" to anyone looking at the finished page.

Double-checking before you send it

Once every field is filled in, it's worth zooming through each page at real size (not just the thumbnail you were typing into) to confirm nothing overlaps, nothing runs past a line's edge, and every required field actually got filled — a text box that looks fine while you're actively editing it can occasionally sit slightly differently once you view the finished page as a whole.

Multi-page contracts, reports, and forms need a slightly different approach than a quick one-page edit — mainly around keeping things consistent as you move through the document.

Navigating between pages without losing your place

Context's page navigation keeps every text box tied to the specific page it was placed on, so moving between pages to fill in different sections of a long document doesn't risk mixing anything up — a box added on page 3 stays on page 3 regardless of how many other pages you visit before downloading.

Keeping size and color consistent across pages

For anything with a repeated structure across pages — the same kind of label appearing on every page of a multi-page form, for instance — deliberately reusing the same font size and color each time keeps the finished document looking like one coherent pass rather than several inconsistent edits stitched together. Since the last size and color you used carry forward automatically to the next text box you add, staying consistent across a long document usually just means not changing them unless you actually mean to.

Planning a pass before you start typing

For longer documents, it's worth a quick first pass through every page — just looking, not yet typing — to see the full scope of what needs to be filled in before committing to a size and position on page one. A size that looks right on a sparse first page can turn out too large for a denser page further in, and catching that early saves having to go back and resize boxes you've already placed.

Reviewing the whole document before downloading

Because each page renders and edits independently, it's easy to focus closely on whichever page you're currently working on and lose track of the document as a whole. Before downloading, page back through from the start — it's the only way to catch a page that got skipped entirely, or a box that ended up looking different from the others without you noticing while working through the file.

Most issues with an edited PDF trace back to a small set of easy-to-miss mistakes. Here's what to watch for.

Text that's too small once zoomed back out

It's easy to type at a size that looks perfectly readable while you're zoomed in and focused on a single box, only to find it's noticeably small once the page is viewed at its normal, full size. Zoom back out (or check the finished PDF in a separate viewer) before downloading to confirm every box is actually legible at real size, not just at editing size.

Placing text over existing content instead of beside it

Dropping a text box directly on top of printed text or a line makes both hard to read once they overlap — the underlying content doesn't move out of the way. Nudge new text into genuinely empty space nearby instead of stacking it directly on something that's already printed there.

Editing the wrong page

On a longer document it's easy to lose track of which page is currently active, especially after zooming or scrolling, and end up adding text to the wrong page entirely. Check the page indicator before adding a box on anything beyond a single-page document, particularly right after navigating to a new page.

Using a color with poor contrast

Light colors — pale yellow especially — can look fine at editing size on a bright screen and then become genuinely hard to read once printed or viewed on a different display. Stick to colors with strong contrast against white, like black or a saturated color, for anything that actually needs to be read rather than just noticed.

Forgetting to rename the file before sharing

Downloading straight from a generic uploaded filename can leave you (or whoever you send it to) with a file simply called "document" or similar, indistinguishable from a dozen other files with the same default name. Taking a moment to give it a clear, specific filename before downloading — what it is, and often the date — saves real confusion later, especially once several versions of the same form start accumulating in a downloads folder.

The GIF format is decades old and technically primitive compared to modern video, yet it's never gone away — it's the one moving-image format that plays automatically everywhere, with no player controls, no sound, and no "click to play" barrier. Understanding what it actually is explains both its limits and why Congify's settings are shaped the way they are.

What a GIF actually is

A GIF isn't compressed video — it's a sequence of individual images, each limited to a palette of at most 256 colors, played back one after another in a loop. There's no audio track at all, and no way to add one; a GIF is silent by definition, which is exactly why it plays automatically in places a video wouldn't (chat apps, social feeds, forum posts) without needing a mute button or a tap to start.

The 256-color limit is the format's biggest technical constraint. It's not the same as JPG's lossy compression, which blurs detail to save space — a GIF genuinely cannot display more than 256 distinct colors in a single frame, so smooth gradients and photographic color depth get reduced to a smaller palette. For most everyday clips (screen recordings, reaction clips, short bits of footage with a handful of dominant colors) this is invisible or close to it; for a sunset with a wide, subtle color gradient, you'll sometimes see visible banding.

Frame rate: the fps trade-off

Congify offers 5, 10, 15, or 20 frames per second. Every additional frame is another full image added to the file, so frame rate is the single biggest lever on file size — going from 10fps to 20fps roughly doubles the number of frames (and roughly doubles the file size) for the same clip length, for a smoothness improvement that's often hard to even notice at GIF resolutions and typical viewing sizes.

10fps is a reasonable default for most clips — motion reads as fluid without ballooning the file. Drop to 5fps for anything long or mostly static (a slide of text, a slow pan) where fewer frames won't be noticeable. Reach for 15-20fps only when the motion itself is fast and choppiness would actually be distracting — quick gameplay, fast hand gestures, anything with a lot of frame-to-frame change.

Size and crop: Full, Square, Portrait

Full keeps the source video's original aspect ratio untouched — the safest default when you're not sure where the GIF is going to end up. Square (1:1) crops to a centered square, which is what most social platforms display cleanly in a feed without letterboxing or cropping unpredictably on their end. Portrait suits stories and vertical-video placements, where a landscape clip would otherwise show up small with bars on either side.

Cropping happens before the GIF is generated, not after, so whatever's cut off by Square or Portrait is genuinely gone from the output — it's worth previewing the crop against your actual subject (is the important part of the frame centered?) rather than assuming it'll always land right.

The quick decision rule

Short, everyday clip with people or motion → 10fps, Full. Posting to a feed that crops to square anyway → Square, so you control the crop instead of the platform. Long or mostly-still footage → drop to 5fps first, before reaching for any other size reduction.

The single biggest thing you control over a GIF's file size and how well it actually reads isn't fps or crop — it's how much footage you feed it in the first place. Trimming well matters more than any setting after it.

Why shorter is almost always better

A GIF loops, which means the viewer generally sees it more than once — a good GIF earns a second and third loop rather than needing one to even register what happened. Trimming down to just the moment that matters (a gesture, a reaction, a punchline, a specific bit of screen action) instead of the few seconds around it almost always produces something more effective, not just smaller — a GIF that requires 10 seconds to make sense usually isn't a good candidate for a GIF at all.

File size scales directly with clip length — a 6-second trim is roughly twice the file size of a 3-second trim at the same fps and size settings, all else equal. Since GIFs are so often shared over chat apps and slower connections, trimming tight is usually a bigger win than dropping fps or cropping smaller.

Using the scrubber precisely

Drag the two handles on the filmstrip to set exactly where the clip starts and ends — the preview updates live so you can see precisely what you're keeping before committing to a frame rate or size. Scrub through slowly around the in and out points especially; a half-second of dead air at the start or a lingering extra frame at the end is a common reason a trimmed GIF feels less punchy than the moment you originally had in mind.

Playback direction: Normal, Reverse, Boomerang

Normal plays the trimmed clip once through, looping from the end straight back to the start — fine for most footage, but that hard cut back to the beginning can look abrupt if the first and last frames don't naturally match. Reverse plays the same clip backwards, which is mostly useful as a deliberate effect rather than a general-purpose setting. Boomerang plays forward then immediately backward before looping, so the GIF ping-pongs rather than snapping back to the start — it's the setting to reach for whenever the loop point itself would otherwise look jarring, and it's become a familiar, recognizable style in its own right for short looping clips.

Speed: slowing down or speeding up the loop

Speed changes playback rate independently of the fps you extracted the clip at — 0.5x plays back at half speed for emphasis or a slow-motion feel, while 2x or 4x compresses a longer action into a tighter, punchier loop. This is a different control from frame rate: fps decides how many frames exist, speed decides how quickly the GIF cycles through the frames it already has, so a slowed-down GIF at a low fps can still look choppy — pair a slower speed with a higher fps if you need both smoothness and a slow-motion feel.

Captions turn a GIF into something that reads even with the sound off everywhere else on the page — which, since GIFs have no sound at all, is always. Getting them legible against a moving, unpredictable background takes a bit more care than dropping text on a static image.

Font choice and readability

Impact (the classic thick, condensed meme font) reads clearly at small sizes and holds up against busy backgrounds better than a lighter, thinner face — it's a deliberate, practical choice, not just a style default. Arial is the safer, more neutral pick for anything that should read as informational rather than as a meme. Times and Comic Sans are there for when the tone calls for something specific, but neither holds up as well against a moving background at small caption sizes.

Stroke: why outlined text reads better over any background

A GIF's background changes from frame to frame, so text with no outline can be perfectly legible in one frame and nearly invisible in the next if the footage behind it shifts from dark to light. A stroke — an outline in a contrasting color, usually black around white text or white around black text — keeps the caption readable through those changes, since the outline (not just the fill) is what the eye locks onto against a busy or shifting background. Turn it on for almost anything with real background motion; it's one of the few settings worth defaulting to on rather than off.

Color contrast basics

White or yellow text with a black stroke is the classic, reliable combination — it holds up across nearly any footage. Black text can work over consistently light footage, but is riskier the moment any part of the clip goes dark. When in doubt, preview the caption over the darkest and lightest moments in your trimmed clip, not just the frame you happened to be looking at while typing it.

Positioning and multiple captions

Captions can be dragged anywhere within the frame and resized by dragging their corner handle, so there's no fixed "top" or "bottom" placement forced on you — position each one wherever it doesn't cover the part of the footage that actually matters. Congify supports several captions in the same GIF, useful for a multi-beat joke or a labeled sequence, but each one adds visual clutter, so it's worth asking whether a single, well-placed line does the job before stacking several.

A GIF isn't always the right answer just because the source is a video clip — knowing when it genuinely beats the alternatives saves you from a bloated file that a video would have handled better, or a caption-only image that didn't need motion at all.

Messaging apps and reactions

This is the format's home turf — a GIF drops straight into a chat and plays immediately, no tap, no loading spinner, no separate video player. For a quick reaction, a repeatable loop, or a short clip meant to land instantly in a conversation, nothing else behaves this way.

Social media posts

Most platforms will auto-convert an uploaded GIF into a looping video internally anyway, so the practical difference from posting an MP4 directly is often small — but a GIF is still the safer choice if you're not sure a given platform or embed will treat an uploaded MP4 the same way (autoplay, no sound icon, no player chrome).

Documentation and tutorials

A short, looping GIF is genuinely excellent for showing a single repeatable UI action — click this, drag that, watch this menu open — because it loops on its own without the reader needing to hit play or scrub back to re-watch it. For anything longer than a few seconds, or anything that needs narration, a real video with actual playback controls serves the reader better than a long, silent, autoplaying loop.

Email and presentations

Support for animated GIFs in email clients and presentation software is inconsistent — some render every frame as intended, others show only the first frame as a static image. If the animation is essential to what you're communicating in one of these contexts, it's worth testing in the actual destination first rather than assuming it'll animate the way it does in a browser.

Most disappointing GIFs come down to a small set of avoidable choices made early in the process, before a single caption or crop setting even comes into play.

Cranking fps all the way up by default

It's tempting to reach for 20fps every time on the assumption that higher is simply better, but for most everyday clips the smoothness gain over 10fps is barely visible while the file size roughly doubles. Save the higher frame rates for footage where the motion is genuinely fast enough to need them.

Trimming too loosely

A few extra seconds of runway before and after the actual moment doesn't just inflate the file — it also dilutes the point of the GIF, forcing the viewer to sit through setup that a tighter trim would have cut straight past. When in doubt, trim tighter than feels comfortable and check the preview; it's rarely too short.

Captions with no stroke over busy footage

Text that looked perfectly readable against the one frame you were staring at while typing it can disappear entirely a second later once the background shifts. Turning stroke on by default for anything with real background motion avoids re-discovering this after the GIF's already been shared.

Ignoring file size on a mobile connection

A long, high-fps, full-size GIF can end up several times larger than the same clip would be as a properly encoded video — and unlike a video, a GIF can't be "paused before it fully loads" in most places it's shared, so the whole file has to arrive before it plays at all. If a GIF is coming out unexpectedly large, trimming shorter and dropping fps are the two settings worth checking first, well before reaching for a smaller crop.

Audio formats split along the same lossy-vs-lossless line image formats do, and the same underlying question decides which one you actually want: are you preparing something to listen to and share, or something to keep in the best possible quality for further work?

MP3: the lossy, universal format

MP3 uses lossy compression, discarding audio detail that's harder for human hearing to notice in order to shrink the file dramatically — often to a tenth the size of the uncompressed original, or smaller, depending on the bitrate used. It's supported by essentially everything: every phone, every car stereo, every music app, every website. For listening, sharing, and everyday use, MP3 is almost always the right default.

The tradeoff is the same as JPG's: some detail is genuinely gone after compression, and it doesn't come back if you later convert the MP3 to something else. For casual listening this is inaudible at reasonable bitrates; for critical listening, mastering, or archival, it starts to matter.

WAV: the lossless, uncompressed format

WAV stores audio uncompressed — every sample preserved exactly, with no data thrown away. This makes it the right choice for anything that will be edited, mixed, or processed further, since lossy compression artifacts don't stack on top of each other through multiple rounds of editing the way they would with a repeatedly re-saved MP3. It's also the standard format for archival masters, since it's the closest thing to keeping the original recording intact.

The cost is size: WAV files are typically 5-10x larger than an MP3 of the same audio at a reasonable bitrate, since there's no compression doing any of the work. A few minutes of WAV audio can already be tens of megabytes, which matters if you're emailing it or storing a lot of it.

The quick decision rule

Sharing, listening, uploading to most platforms → MP3. Editing, mixing, or archiving a master copy you'll come back to → WAV. Not sure, and it's a one-off → MP3 is the safer default; almost everything can play it.

Bitrate is the one MP3 setting that actually matters for both file size and quality, and picking a sensible number for what you're doing is worth understanding rather than guessing at.

What bitrate actually controls

Bitrate is how much data is used to encode each second of audio, measured in kilobits per second (kbps). A higher bitrate keeps more of the original detail and sounds closer to the uncompressed source; a lower bitrate compresses harder, discarding more, in exchange for a smaller file. It's a direct, roughly linear trade: doubling the bitrate roughly doubles the file size for the same length of audio.

Matching bitrate to what you're actually encoding

Spoken word — podcasts, voice memos, audiobooks, narration — doesn't need a high bitrate at all; voice has far less complexity than music, and even a low bitrate sounds clear and perfectly intelligible while keeping file sizes small. Music, especially anything with a wide dynamic range or lots of simultaneous instruments, benefits from a meaningfully higher bitrate before compression artifacts (a slight harshness or "underwater" quality on complex passages) become audible.

There's a genuine diminishing-returns point on the high end: past a certain bitrate, most listeners on typical headphones or speakers can no longer reliably tell the difference from the source, so cranking the number higher just inflates the file without a perceptible quality gain. If you're not sure, a mid-range bitrate is the safe general-purpose choice — noticeably better than low-bitrate voice settings, without the file size of a maximum-quality music-mastering setting you don't need for everyday sharing.

When bitrate doesn't matter at all

If you're converting to WAV instead of MP3, bitrate is irrelevant — WAV is uncompressed, so there's no bitrate setting to choose in the first place. Bitrate only comes into play once you're deliberately trading some quality for a smaller file, which is the entire premise of choosing MP3 over WAV to begin with.

Coudio doesn't just convert existing audio files — it can also pull the audio track out of a video and give you just the sound, discarding the picture entirely.

Common reasons people need this

Turning a recorded lecture, meeting, or interview video into a podcast-style audio file that's far smaller and easier to listen to on the go. Pulling a song or sound clip out of a video when only the audio is actually needed. Archiving just the audio portion of old video footage to save on storage. Converting a screen recording's voiceover into a standalone audio file for editing or transcription elsewhere.

How it actually works

Drop an MP4, WEBM, MOV, or OGV file into Coudio the same way you'd drop an audio file — the tool detects it's a video and extracts the audio track automatically, discarding the picture. Pick MP3 or WAV as the output the same way you would for a regular audio file, and (for MP3) choose a bitrate. The video itself is never re-encoded or altered; only its existing audio track is pulled out.

What happens if the video has no audio track

A video with no sound at all — a muted screen recording, footage shot without audio — has nothing for Coudio to extract, since there's no audio track present in the file to begin with. This isn't something the tool can work around; if the original recording genuinely has no sound, there's no audio to pull out of it.

Podcasts, voice notes, and spoken word

MP3 at a modest bitrate is the standard here — file size matters more than it does for music, since episodes are often long, and speech tolerates compression exceptionally well without any audible quality loss for the listener.

Music you're sharing or listening to

MP3 at a mid-to-higher bitrate covers nearly every everyday case: sending a track to a friend, uploading to most platforms, keeping music on a phone where storage space adds up. Reach for WAV only if you specifically need the uncompressed original — for editing, sampling, or a truly critical-listening archive.

Audio you'll edit or mix later

WAV avoids stacking additional compression loss on top of whatever editing you do — mixing, trimming, layering, adjusting levels — since there's no lossy compression in the file to begin with. Convert to MP3 only as the final export step, once editing is done, the same rule that applies to repeatedly re-saving a JPG.

Long-term archiving

For anything you want to preserve at the best possible quality indefinitely — an original recording, a master track, an important interview — WAV is the safer long-term choice, since it never loses any additional detail no matter how many times it's copied or backed up.

Most audio quality complaints trace back to one of a small handful of avoidable choices.

Converting MP3 to MP3 repeatedly

Just like re-saving a JPG, re-encoding an already-compressed MP3 back into MP3 loses a little more detail each time — the second compression pass has less original information to work with than the first did. Where possible, keep and edit from a lossless source (WAV) and only export to MP3 once, at the end.

Using a bitrate that doesn't match the content

A low bitrate that's perfectly fine for spoken word will sound noticeably compressed on music with a full instrumental mix, while a maximum bitrate on a simple voice memo just wastes file size for no audible benefit. Match the bitrate to what's actually in the recording, not a single number used for everything.

Not checking for an audio track before extracting

Trying to pull audio from a video that was recorded muted, or where the audio was stripped out earlier in some other step, will come back empty — there's nothing there to extract. Worth a quick check (or a quick listen to the original video) before assuming the extraction failed on Coudio's end rather than the source simply having no sound.

Ignoring file size for long recordings

A long lecture or meeting recording exported as WAV, or at an unnecessarily high MP3 bitrate, can balloon to a size that's awkward to email or upload. For long spoken-word content especially, a modest MP3 bitrate keeps the file manageable without any real loss in intelligibility.

A plain-text code snippet pasted into a chat, slide, or social post loses everything that makes real code easy to read at a glance — no syntax color, no consistent spacing, often no line breaks preserved at all. A styled screenshot fixes that, but only if it's actually legible at the size it'll be viewed at.

Why syntax highlighting isn't just decoration

Color-coding keywords, strings, comments, and function names isn't cosmetic — it's a real reading aid. Experienced developers scan highlighted code by shape and color before reading it word by word, which is exactly why plain, uncolored code in a screenshot or a low-contrast messaging app reads noticeably slower, even for someone fluent in the language.

Keeping the snippet short

A code screenshot is meant to be read at a glance, not scrolled through — the moment a snippet needs to shrink past a comfortable reading size to fit the frame, it's usually a sign the excerpt is too long for a screenshot and would serve the reader better as a linked file or a gist. Trim to just the lines that make the point; a shorter, larger, more legible snippet beats a complete-but-tiny one almost every time.

Picking a size that's actually readable where it'll be posted

A screenshot that looks perfectly sharp at full size on your own monitor can shrink to illegible in a chat thumbnail, an embedded tweet, or a slide viewed from the back of a room. If you know where the image is headed, preview it at roughly that size before finalizing — what's comfortable to read full-screen is not always comfortable to read as a thumbnail.

The four themes aren't just different color palettes for their own sake — each comes from (or closely follows) a real, widely-used editor theme, and picking one that looks familiar to your audience can matter as much as picking one that looks good.

Dracula: high-contrast and distinctive

Dracula's dark purple background with vivid pink, green, and cyan highlights is one of the most recognizable editor themes in use today — instantly familiar to a huge share of developers, and high-contrast enough to stay readable even shrunk down small. It's a strong default when you're not sure who's looking or where the image will end up.

VS Code Dark: the most common baseline

Since Visual Studio Code is the most widely used code editor, its default dark theme is the one the largest number of viewers will already associate with "what code normally looks like" — a safe, unsurprising choice, especially for an audience that's likely to include VS Code users specifically (which, statistically, is most developers).

Monokai: warm and long-established

Monokai predates most of the newer themes and carries a distinct, warm palette — olive background undertones, orange and pink accents — that a lot of developers who've used Sublime Text or older setups will immediately recognize. It reads slightly softer in contrast than Dracula, which some people find easier on the eyes for longer viewing.

GitHub Light: the one for bright contexts

All three of the above are dark themes; GitHub Light is the one genuinely light option, matching GitHub's own default code rendering. It's the right pick for a slide deck or document that's otherwise light-themed, where a dark code block would stand out as a jarring, disconnected rectangle rather than fitting the surrounding design.

Picking the correct language isn't just a label — it's what tells the highlighter which words are keywords, which are strings, and which are comments, so getting it right (or wrong) has a direct, visible effect on the result.

What happens if you pick the wrong language

Highlighting is done by pattern-matching against a specific language's syntax rules, so picking the wrong one produces confidently-wrong results rather than an error — keywords in a different language might not get colored at all, or worse, some other word gets miscategorized and colored as if it were a keyword. Always double-check the language selector matches what's actually in the box, especially after pasting from a template or switching languages mid-edit.

Mixed-language snippets

A snippet that embeds one language inside another — SQL inside a Python string, HTML inside a JavaScript template literal — will only get highlighted correctly for whichever single language is selected; there's no way to highlight both at once within one snippet. For genuinely mixed content, pick whichever language makes up the bulk of the snippet, or split it into two separate screenshots if both halves need to read clearly.

When highlighting doesn't matter much

For very short snippets — a single line, a short config value, a one-line command — the specific language matters much less, since there's little enough content that a reader can parse it correctly regardless of coloring. It matters most for longer, structurally complex snippets where color is genuinely doing work to separate logic, strings, and comments from each other.

Social media and chat apps without code support

Most social platforms have no concept of a formatted code block at all — paste raw code into a tweet or a post and it loses all indentation, line breaks, and coloring, often collapsing into an unreadable wall of text. A screenshot sidesteps this completely, since it's just an image and renders identically everywhere images do.

When the recipient needs to actually use the code

A screenshot is a picture — it can't be selected, copied, or pasted back into an editor. If whoever you're sending it to actually needs to run, edit, or copy the code (not just look at it), plain text, a live snippet in a chat app that supports one, or a gist link serves them far better than an image they'd have to manually retype from.

Documentation and technical writing

A real, text-based code block in documentation is searchable, screen-reader accessible, and copyable — all things a screenshot gives up. Screenshots earn their place in docs mainly for showing something screenshots are actually good at: an annotated UI, a diff highlighted a specific way, or code as it appears in a specific editor for illustration rather than for the reader to copy.

Longer examples and full files

A code screenshot works best for a focused excerpt someone can read in a glance or two — for a full file, a multi-function example, or anything that would require scrolling a tall image, a gist or repository link is the more practical and more usable choice.

Most code screenshots that end up hard to read share one of a handful of avoidable causes.

Including far more code than the point requires

A screenshot with 40 lines of surrounding context to show one relevant line asks the reader to hunt for what matters. Trim to just the lines that make the point — imports, boilerplate, and unrelated functions can almost always be cut without losing the actual message.

Picking the wrong language for the syntax highlighter

Leftover language selection from a previous snippet, or picking the closest-sounding option instead of the exact one, produces subtly wrong highlighting that's easy to miss at a glance but reads as off to anyone who knows the language. Double-check the language matches before exporting, especially after pasting in a template.

A theme that clashes with where it's being posted

A dark-themed screenshot dropped into an otherwise bright, light document or slide stands out as a jarring rectangle rather than fitting the design around it — GitHub Light exists specifically for this case, so it's worth switching to it rather than defaulting to a dark theme everywhere out of habit.

Exporting at a size too small to read once shared

What's crisp and legible at full size on your own screen can shrink to illegible once it's a thumbnail in a chat app or a small embed in a social post. If you know where it's headed, check the image at roughly that display size before calling it done — a shorter, larger-text snippet often communicates better than a longer one shrunk to fit.