DEV Community: Celio Bitran

Why Some Links Turn Into a Card and Others Just Sit There

Celio Bitran — Sun, 19 Jul 2026 13:17:06 +0000

You drop a link into a group chat and watch it transform. Within a second the bare address folds itself into a tidy card: a headline, a sentence of description, a thumbnail image, the name of the site. It looks finished, trustworthy, clickable. A minute later you paste a link to your own page — your shop, your portfolio, the article you just published — and nothing happens. It just sits there as a stark blue line of text, naked and a little sad, giving whoever sees it no reason at all to tap it. Same chat app, same kind of link, completely different first impression. The gap between those two outcomes is not luck, and it is not the app playing favorites.

The preview is a message you did not know you were writing

When you share a URL, the app on the other end does something invisible: it quietly visits the page and looks for a small set of instructions buried in the page’s code — a title to show, a short description, an image to display, a site name. If those instructions are there, it assembles them into the rich card everyone recognizes. If they are missing, it has nothing to work with, so it falls back to the plainest possible thing: the raw link. The card is not generated by the chat app out of thin air. It is written, in advance, by whoever made the page — whether they meant to or not.

This is the part most people never realize they control. The little preview that shows up when your link is shared on a phone, in a chat, on social media, or in a work channel is a message you are sending on every share, forever. You either wrote it deliberately, or you left it blank and let the internet decide what your link looks like. And a blank one always looks like the least cared-for option in the thread.

Where a bare link quietly costs you

This is not a problem reserved for marketers obsessing over click rates. It shows up in ordinary moments, over and over:

A freelancer sends a prospective client the link to their portfolio, and it lands as a plain URL next to three competitors whose links all show polished preview cards.
A small-business owner posts their new shop to a community group, and where everyone else’s links have product photos, theirs has nothing — so it reads as less real.
A writer publishes a piece they are proud of, shares it, and the link gives no hint of what it is about, so most people scroll past without clicking.
A team drops an internal doc into a work channel and it appears as a cryptic string, forcing everyone to click blindly just to find out what it is.
Anyone sending a link to a friend who is even slightly cautious about tapping something that looks like it could be spam or a broken address.

In every one of these, the page itself is fine. The content behind the link is good. The only thing missing is the two-second impression the link makes before anyone visits — and that impression is doing more persuading, or more damage, than the page it points to ever gets the chance to.

What a good preview is actually made of

A rich link card is assembled from a handful of specific ingredients. Knowing them takes the mystery out of why some links look great and yours does not:

A title — the bold headline of the card. Without it, apps fall back to the domain name or nothing at all.
A description — the sentence under the title that tells someone what they will get if they click. This is your one line of persuasion.
A preview image — the single biggest visual driver of whether a card catches the eye. A link with a crisp image gets noticed; a link without one is easy to skip.
A site name — the small label that signals the card came from a real, identifiable place rather than a random address.
A little icon in the browser tab — the tiny mark that shows up beside the page title, another quiet signal that the page is cared for and legitimate.

Different platforms read slightly different versions of these instructions — one social network looks for its own set of tags, another for a more general standard — but they overlap heavily, and covering the common ones means your link looks right almost everywhere it travels. The image deserves special attention: it usually wants specific proportions so it fills the card cleanly instead of being awkwardly cropped, and it needs to be sized sensibly so it loads fast rather than making the preview hang.

Why so many links are naked in the first place

If these instructions matter so much, why are so many links missing them? Partly because they are invisible — you never see the tags while building a page, only their absence when a shared link looks wrong, and by then you have moved on. Partly because getting them right means hand-writing a block of finicky code with exact attribute names, and one typo means an app silently ignores the whole thing. And partly because you cannot easily tell it worked: the preview is generated on someone else’s server when they share the link, so you are shipping blind and only finding out it is broken when you spot your own bare link in a chat weeks later.

That combination — invisible, fiddly, and hard to verify — is exactly why the task gets skipped. It is not that people decide their links should look plain. It is that the work of making them look good never surfaces as an obvious to-do.

Turning a bare link into a card

The fix is a small, one-time job: generate the right set of preview instructions for a page, drop them into its code, and from then on every share of that link unfurls into a proper card instead of sitting there bare. The useful part is being able to fill in the title, description, and image and see the resulting card previewed before it goes live, so you are not shipping blind. A couple of adjacent details make it land properly — sizing and compressing the preview image so it fills the card without dragging the load time, and giving the page a clean tab icon so the small signals line up with the big one. Set it once per page, and the next time you paste your own link somewhere, it shows up looking like the ones you used to envy.

Everything on Boxtool runs client-side — your files never leave the browser. If this was useful, the meta tags and 40+ other free tools are at boxtool.io.

How to Compress a PDF Without Losing Quality

Celio Bitran — Fri, 17 Jul 2026 13:02:29 +0000

You have a PDF that needs to go out — an email attachment with a 25 MB limit, an upload form that rejects anything over 10 MB, a portfolio you want to load instantly. The file is too big, and the obvious question is: how do you make it smaller without turning your crisp document into a blurry mess? The good news is that most oversized PDFs are bloated for predictable reasons, and once you understand those, compression becomes a deliberate choice rather than a gamble.

What actually makes a PDF large

A PDF is a container. Text and vector graphics inside it are tiny — a 50-page text-only contract often weighs less than a megabyte. The weight almost always comes from embedded raster images: scanned pages, screenshots, product photos, and high-resolution graphics. A single 12-megapixel phone photo dropped into a document can add several megabytes on its own. Other common culprits are embedded fonts (especially full Unicode font families), duplicated images that appear on every page, and metadata or revision history left behind by the software that created the file.

This matters because it tells you where the savings are. If your PDF is mostly text, there is very little to compress and you should be suspicious of any tool promising a 90% reduction — it is probably degrading your images aggressively. If your PDF is mostly scans or photos, you have enormous room to shrink it with barely perceptible quality loss.

How PDF compression works

There are two broad strategies, and good compressors use both. The first is lossless optimization: removing redundant data, deduplicating repeated images, subsetting fonts so only the characters you actually use are embedded, and re-encoding streams more efficiently. This shrinks the file with zero quality impact. The second is lossy image recompression: downsampling images to a sensible resolution (you rarely need 600 DPI for a document viewed on screen) and re-encoding them with a controlled quality level. This is where the real size reductions happen, and also where quality can suffer if you push too far.

Choosing the right compression level

Most compression tools offer a few presets. Here is how to think about them:

Light / High quality: minimal downsampling, high image quality. Use this for documents you will print, or anything with photos that need to look sharp. Expect modest size savings.
Balanced / Medium: moderate downsampling to around 150 DPI and a sensible image quality. This is the sweet spot for documents meant to be read on screen and shared by email — large savings, quality loss most people never notice.
Strong / Small: aggressive downsampling and lower image quality. Use this only when file size is the hard constraint (a strict upload limit) and the document is reference material rather than something to admire.

A reliable rule of thumb: start with Balanced. Open the result, zoom to 100%, and check the images. If they look fine — and they usually will — you are done. If you need more savings, step down one level and check again. Compression is reversible in the sense that you still have your original, so there is no risk in experimenting.

Why doing it in your browser matters

Many free online compressors work by uploading your PDF to their servers, processing it there, and sending it back. For a meme that is fine. For a signed contract, a medical record, a tax return, or an unreleased business document, it is a real privacy problem — your file now exists on a third party’s infrastructure, subject to their retention policy and their security (or lack of it).

This is the case for choosing a compressor that works locally, right in your browser. When the file is read, recompressed, and saved on your own device instead of travelling to a server, it stays safe to use with confidential material — and there is no upload wait, because the work happens at the speed of your machine rather than your connection.

A quick workflow

Open a PDF compressor and drop your file in.
Pick the Balanced preset to start.
Compare the resulting file size against your limit.
Open the output and check the images at 100% zoom.
If you need it smaller, drop to the next level; if quality slipped, move up one.
Download. Your original is untouched, so you can always retry.

The same thinking covers more involved jobs — merging several PDFs before compressing, splitting out only the pages you need, or rotating scanned pages. And if the real problem is one giant embedded image, resizing it before it ever goes into the document is often the cleanest fix of all. None of it needs to be complicated, and none of it needs your file to leave your computer.

Everything on Boxtool runs client-side — your files never leave the browser. If this was useful, the pdf compressor and 40+ other free tools are at boxtool.io.

The Complete Guide to QR Codes: Error Correction, Logos, and Best Practices

Celio Bitran — Tue, 14 Jul 2026 13:02:27 +0000

A QR code is one of those technologies that looks trivial and turns out to have real depth. Generate one carelessly and it might scan fine on your phone in good light, then fail completely on a printed flyer under a fluorescent bulb. The difference between a code that always works and one that frustrates people comes down to a handful of decisions you make when you create it.

What a QR code actually stores

A QR (Quick Response) code is a two-dimensional barcode that encodes data as a grid of black and white modules. It can hold a URL, plain text, contact details, Wi-Fi credentials, an email address with a pre-filled subject, a phone number, and more. The most common use by far is a URL: the code is just a compact, camera-friendly way to type a web address for someone. The amount of data you encode affects the density of the grid — a short URL produces a sparse, easy-to-scan code, while cramming in a long string makes the modules small and harder for cameras to resolve.

Error correction: the most important setting

QR codes have built-in redundancy using Reed–Solomon error correction. This is what lets a code still scan when part of it is dirty, damaged, or covered. You choose how much redundancy to include, and the choice is a genuine trade-off:

Level L (Low) — recovers ~7% of the code. Maximum data capacity, least resilience. Fine for clean digital display.
Level M (Medium) — recovers ~15%. The default for good reason; reliable in most real-world conditions.
Level Q (Quartile) — recovers ~25%. A good step up for print that may get handled or scuffed.
Level H (High) — recovers ~30%. Essential if you plan to place a logo over the code, or expect physical wear, smudging, or partial obstruction.

Higher error correction makes the grid denser (more modules to hold the redundant data), so it is not a free upgrade — push it to H with a long URL and the code can become too dense to scan from a distance. The practical answer: use M for screens and clean print, and only jump to H when you are adding a logo or printing something that will take abuse.

Adding a logo without breaking the code

A logo in the center of a QR code looks professional and on-brand, and it works because of error correction — the code treats the logo as "damage" it can recover from. The rules are simple but firm: set error correction to H, keep the logo to roughly 20–30% of the code’s area, and keep it centered. Cover too much, or place it over the three large corner squares (the finder patterns that cameras use to locate and orient the code), and scanning breaks. After adding a logo, always test the code with several phones before you publish or print it.

Contrast, color, and the quiet zone

Scanners need clear contrast between the dark modules and the light background. Dark-on-light is the safe default. You can use brand colors, but keep the foreground genuinely dark and the background genuinely light — a medium blue on a medium gray will fail. Critically, never invert the code (light modules on a dark background) unless you have tested extensively, because many scanners assume dark-on-light.

The "quiet zone" is the empty margin around the code. It is not decoration — scanners rely on it to separate the code from surrounding content. Always leave a clear margin of at least four modules’ width on all sides. Codes that bleed into busy backgrounds or sit flush against text are a common cause of scan failures.

Choosing a file format

Download as SVG for anything that will be printed or scaled — it is a vector, so it stays razor-sharp at any size, from a business card to a billboard. Use PNG for digital use where you want a crisp raster with a transparent or solid background. JPEG is the weakest choice for QR codes because its compression introduces artifacts around the sharp edges of the modules; avoid it unless file size is the only thing that matters.

Common mistakes that break codes

Encoding a very long URL — shorten it first so the grid stays sparse and scannable.
Printing too small — a code needs roughly 2×2 cm minimum for close scanning, larger for distance.
Insufficient contrast or an inverted color scheme.
No quiet zone, or the code placed over a busy photo background.
A logo that is too large or covers a finder pattern.
Never testing the printed result — always scan the final artifact, not just the screen.

A good QR generator lets you control all of this — input type, colors, size, and error-correction level, with PNG, SVG, and JPEG export. If your destination link is long, shortening it first produces a cleaner, more reliable code. Generate it, download it, and then do the one step most people skip: scan the final version with a couple of different phones before you ship it.

Everything on Boxtool runs client-side — your files never leave the browser. If this was useful, the qr code and 40+ other free tools are at boxtool.io.

Why Browser-Based Tools Are Safer for Your Sensitive Files

Celio Bitran — Sun, 12 Jul 2026 13:02:26 +0000

Every day, people drop deeply personal files into random websites: passport scans into an "image to PDF" converter, salary spreadsheets into a "CSV to JSON" tool, signed contracts into a "compress my PDF" page. Most of those sites work by uploading your file to a server somewhere, processing it there, and handing it back. The convenience is real, but so is the cost — and most people never think about it.

Server-side vs. client-side, in plain terms

A server-side tool sends your file across the internet to a computer the website owns. Your file is now a copy on someone else’s machine, subject to their security, their employees’ access, their retention policy, their backups, and their jurisdiction’s laws. Even if they promise to delete it "immediately," you are trusting that promise with no way to verify it.

A client-side tool does the opposite: it runs the processing code inside your own browser, on your own device. Modern browsers are remarkably capable — they can resize images, manipulate PDFs, hash files, transcode audio, and parse spreadsheets entirely in JavaScript and WebAssembly. With a true client-side tool, your file is opened, processed, and saved locally. It never leaves your computer. There is no upload, no copy on a server, and nothing to leak.

Why this matters more than it seems

The risk is not that a tool maker is necessarily malicious. The risk is exposure surface. Every file you upload is one more copy that could be breached, subpoenaed, retained longer than promised, indexed, or accessed by someone who should not see it. For ordinary files that is a small risk. For the documents people most often need to convert — IDs, financial records, legal agreements, medical paperwork, anything with personal data — it is exactly the wrong category of file to be scattering across third-party servers.

Client-side processing collapses that exposure surface to zero. If the file never leaves your device, there is no server copy to breach in the first place. This is the strongest form of privacy: not a promise to protect your data, but an architecture where the sensitive data is never collected at all.

A real example: image metadata

Photos carry hidden EXIF metadata — often including the exact GPS coordinates where the picture was taken, the device, and the timestamp. People strip this before posting images publicly, for good reason. But uploading a photo to a server just to remove its location data is self-defeating: you have now handed that exact location data to the server in the process. A client-side EXIF editor removes the metadata on your device, so the sensitive information is never transmitted anywhere. The tool that protects your privacy has to be one that never sees your data.

How to tell if a tool runs locally

It says so explicitly — phrases like "runs in your browser," "no upload," or "your files never leave your device."
Speed on large files: a true client-side tool processes a big file at your machine’s speed with no upload progress bar, while a server tool stalls on the upload first.
It works offline: many client-side tools keep functioning after the page has loaded even if you disconnect from the internet.
You can verify in your browser’s developer tools — open the Network tab and confirm your file is not being sent in a request.

The tools worth choosing

The principle is simple: the most private tool is one that never receives your data in the first place. Image conversion, PDF edits, hashing, EXIF cleanup, audio and video conversion — all of it can run client-side, in the browser, with your files staying on your own device. When a tool is built that way, you get the convenience of a web app with the privacy of desktop software, and there is simply nothing sitting on someone else’s server to leak.

The next time you reach for a quick online converter, pause for a second on what is in the file. If it is anything you would not want on a stranger’s hard drive, make sure the tool you use keeps it on yours.

Everything on Boxtool runs client-side — your files never leave the browser. If this was useful, the pdf and 40+ other free tools are at boxtool.io.

Image Formats Explained: JPG vs PNG vs WebP vs AVIF

Celio Bitran — Thu, 09 Jul 2026 13:15:59 +0000

Choosing an image format feels like it should be simple, and then you are staring at a dropdown with JPG, PNG, WebP, and AVIF wondering which one will not ruin your picture or balloon your file size. Each format was designed to solve a different problem. Once you know what each is good at, the choice is usually obvious.

Lossy vs. lossless: the core distinction

Lossy compression throws away image data that the human eye is unlikely to miss, in exchange for dramatically smaller files. The trade-off is that quality degrades — and degrades further every time you re-save. Lossless compression preserves every pixel exactly, producing larger files but perfect fidelity, and you can re-save it endlessly with no decay. Photos tolerate lossy compression beautifully. Sharp graphics, text, logos, and screenshots do not — lossy compression smears the crisp edges into visible artifacts.

JPG (JPEG): the photo workhorse

JPG is lossy and has been the default for photographs for three decades. It is universally supported by every device, browser, and program in existence, which is its greatest strength. It handles the smooth gradients and complex color of photographs efficiently. Its weaknesses: no transparency support, and it makes a mess of sharp edges, flat color areas, and text, where its artifacts become obvious. Use JPG for photographs when you need maximum compatibility and do not need transparency.

PNG: sharp graphics and transparency

PNG is lossless and supports transparency (including smooth, semi-transparent edges). This makes it the right choice for logos, icons, screenshots, diagrams, and any graphic with sharp lines, flat colors, or text. The cost is file size — a photograph saved as PNG is typically several times larger than the same photo as JPG, with no visible benefit. The rule: PNG for graphics and anything needing transparency; not for photos.

WebP: the modern all-rounder

WebP, developed by Google, supports both lossy and lossless modes and transparency. It typically produces files 25–35% smaller than JPG at equivalent quality, and smaller than PNG for graphics, while supporting transparency in both modes. Browser and device support is now effectively universal. For the web, WebP is usually the best default — you get JPG-like compression for photos and PNG-like features for graphics, in one smaller file. The main caveat is older offline software that may not open it.

AVIF: the efficiency champion

AVIF is the newest of the four, based on the AV1 video codec. It offers the best compression of all — often 50% smaller than JPG at comparable quality — with excellent support for transparency, wide color, and high dynamic range. The trade-offs are encoding speed (it is slower to create) and support, which is good in modern browsers but still patchier than WebP in older software. Use AVIF when you want the smallest possible files for the web and your audience is on current browsers.

A note on SVG

SVG is not in the same family as the others — it is a vector format, describing shapes with math rather than a grid of pixels. That means it scales to any size with zero quality loss and tiny file sizes, which is ideal for logos, icons, and illustrations. It is the wrong tool for photographs, which have no clean geometric description. If you have a logo as a PNG and wish it scaled perfectly, converting or tracing it to SVG is the move.

Quick decision guide

Photograph for the web → WebP (or AVIF for the smallest size on modern browsers).
Photograph needing maximum compatibility → JPG.
Logo, icon, screenshot, or anything with sharp edges/transparency → PNG, or WebP/AVIF lossless.
Scalable logo or illustration → SVG.
Favicon → PNG or SVG source, exported to the icon sizes you need.

In practice, converting between these formats is quick work for any decent image converter — batch jobs and resizing included — so a folder of phone photos becomes web-optimized WebP or AVIF in a single pass. Vector work goes both ways too: rasterizing an SVG to PNG, JPG, or WebP, or tracing a raster image back into a vector. And when you need site icons in every required size, those come from one source image. The point is not the format names; it is that picking the right one, and switching to it, has stopped being a hassle.

Everything on Boxtool runs client-side — your files never leave the browser. If this was useful, the image converter and 40+ other free tools are at boxtool.io.

How to Create Strong Passwords (and Why Length Beats Complexity)

Celio Bitran — Mon, 06 Jul 2026 20:54:30 +0000

For years we were all trained to build passwords like "P@ssw0rd!" — a capital letter, a number, a symbol, exactly eight characters. It turns out that advice was mostly counterproductive. It produced passwords that are hard for humans to remember and easy for computers to guess. Understanding why reveals what actually makes a password strong.

How passwords actually get cracked

Attackers rarely sit there typing guesses into a login form. When a service is breached, attackers get a database of hashed passwords and crack them offline at enormous speed — billions of guesses per second on cheap hardware. They do not start with random strings; they start with dictionaries of real passwords from past breaches, common words, and predictable patterns. The classic "substitute a 3 for an e and add a ! at the end" trick is built into every cracking tool, because everybody does it. Complexity rules made passwords look strong to a human while doing little against a machine.

Why length is what matters

Each additional character multiplies the number of possible combinations an attacker must try. Length adds this resistance exponentially, and it does so far more effectively than swapping a letter for a symbol. A long passphrase made of several random words is both easier to remember and vastly harder to crack than a short, gnarly string of symbols. The math is lopsided: a truly random 16-character password is astronomically stronger than a random 8-character one, regardless of how many symbols the short one contains.

The catch is the word "random." A long password that is a common phrase, a song lyric, or a predictable pattern is weak no matter its length, because it is in the attackers’ dictionaries. Strength comes from length combined with genuine unpredictability.

The rules that actually work

Length first: aim for at least 16 characters. More is better.
Randomness: the characters or words should be genuinely random, not a memorable phrase or a keyboard pattern.
Uniqueness: never reuse a password across accounts. This is the single most important rule.
Use a manager: you cannot remember dozens of long random passwords, and you should not try. A password manager makes uniqueness practical.
Turn on two-factor authentication wherever it is offered — it protects you even if a password leaks.

Why uniqueness is the rule that saves you

When one service is breached, attackers take the leaked email-and-password pairs and try them on hundreds of other sites — your email, your bank, your social accounts. This is called credential stuffing, and it works because most people reuse passwords. A unique password per site means a breach of one account is contained to that one account. Even a moderately strong but unique password is safer in practice than a very strong password you have reused everywhere.

Generating strong passwords

The practical answer is to generate random passwords rather than inventing them, because humans are bad at randomness — we fall into patterns without noticing. A good password generator produces strong, random passwords with adjustable length and character sets, and the best ones do it right on your own device so the password is never transmitted anywhere. Generate a long one, save it in your password manager, and you never need to memorize or even see it again. Pair that habit with two-factor authentication and you have eliminated the most common ways accounts get compromised.

If you are curious how the storage side works — why services keep a hashed version of your password rather than the password itself — seeing hashing in action with an algorithm like SHA-256 is a useful way to build intuition. It makes clear why a breach exposes hashes that then have to be cracked, which is the whole reason length matters so much in the first place.

Everything on Boxtool runs client-side — your files never leave the browser. If this was useful, the password generator and 40+ other free tools are at boxtool.io.

JSON, YAML, CSV, and TOML: When to Use Each Data Format

Celio Bitran — Mon, 06 Jul 2026 18:46:18 +0000

Software spends a surprising amount of its life just moving structured data around: an API returns JSON, a config file is written in YAML or TOML, a report is exported as CSV, a spreadsheet wants tabular rows. These formats are not interchangeable — each was designed for a particular job, and using the wrong one creates friction. Knowing the strengths of each makes you faster and saves you from a category of frustrating bugs.

JSON: the lingua franca of APIs

JSON (JavaScript Object Notation) is the default for data exchange between systems, especially web APIs. It represents nested objects and arrays cleanly, every programming language can parse it, and its rules are strict enough to be unambiguous. That strictness is also its main friction for humans: no comments are allowed, every string needs double quotes, and a single trailing comma makes the whole document invalid. JSON is excellent for machine-to-machine communication and data storage; it is merely tolerable for files humans have to edit by hand.

YAML: configuration humans edit

YAML was designed to be readable and writable by people. It uses indentation instead of braces, supports comments, and drops most of the punctuation that makes JSON noisy. This makes it popular for configuration in tools like CI pipelines and container orchestration. Its strength is also its danger: because structure is defined by indentation, a single misplaced space can silently change the meaning of your file or break it entirely. YAML also has surprising type-coercion quirks (the classic example: the word "no" being read as the boolean false). Use YAML for human-edited configuration, but validate it.

TOML: configuration that stays unambiguous

TOML (Tom's Obvious Minimal Language) aims for YAML's readability without YAML's ambiguity. It uses explicit, INI-like sections and clear key-value pairs, supports comments, and has unambiguous typing. It is less prone to the silent indentation mistakes that plague YAML, which is why a number of modern tools have adopted it for their config files. It is excellent for flat-to-moderately-nested configuration; deeply nested data structures become more awkward in TOML than in JSON or YAML.

CSV: flat, tabular data

CSV (Comma-Separated Values) is the simplest of the four and the right answer for one specific shape of data: flat tables of rows and columns, like a spreadsheet export. It is universally understood by spreadsheet software, databases, and data tools. Its limitation is that it has no concept of nesting — you cannot represent an object-within-an-object cleanly. It also has real-world messiness around quoting, commas inside values, and inconsistent line endings. Use CSV for tabular data destined for spreadsheets or simple import/export; do not try to force hierarchical data into it.

Converting between them

Conversions are common and mostly straightforward, with one thing to watch: structural mismatch. JSON, YAML, and TOML can all represent nested data, so converting among them is usually clean. CSV is flat, so converting nested JSON to CSV requires flattening — a nested key like user.address.city typically becomes a column header using dot notation. Going the other way, from CSV to JSON, gives you a flat array of objects. Understanding this is the key to not being surprised by the output.

Quick rule of thumb:

API responses and data interchange → JSON.
Human-edited config in pipelines and orchestration → YAML (and validate it).
Human-edited config you want to stay unambiguous → TOML.
Flat tabular data for spreadsheets → CSV.

Converting between JSON, CSV, YAML, and TOML is quick, bidirectional work with the right tool — validating the input and flattening or expanding the structure as needed. When you only need to tidy and check a single format — pretty-printing minified JSON, or catching a syntax error in a config file — a formatter is the faster route. And when the source or destination is an actual spreadsheet file, that is its own short conversion.

Done in the browser, none of it requires your data files to leave your machine — which matters when the "data" is a customer export or anything you'd rather not upload. I built a small client-side converter for exactly this at boxtool.io/data-converter: JSON/YAML/CSV/TOML both ways, everything runs locally in the tab. It's free — I mention it only because "runs locally" is the whole point of the article.