DEV Community: Robert Wallace

How to Animate SVG Without JavaScript (Pure CSS Animation)

Robert Wallace — Mon, 06 Jul 2026 06:44:56 +0000

`Every time I see a developer reach for a JavaScript library just to animate an SVG icon, I die a little inside. A spinning loader? A draw-in logo? A hover effect on an illustration? You don't need GreenSock. You don't need Anime.js. You don't need a single line of JavaScript.

CSS can animate SVG directly. It's faster, lighter, and simpler than pulling in a dependency. Here's how to do it.

The Foundation: SVG and CSS Working Together

SVG elements in the DOM are just elements — which means CSS properties like transform, opacity, and custom stroke-* properties apply to them. The key difference from animating HTML elements is that SVG uses its own coordinate system for transforms (centered on the SVG viewBox, not the element's center), and it has special properties for line drawing.

Technique 1: Draw-In Effects with `stroke-dasharray` and `stroke-dashoffset`

This is the most satisfying SVG animation technique. It makes it look like an artwork is being drawn by an invisible pen.

`css
.path {
stroke-dasharray: 1000;
stroke-dashoffset: 1000;
animation: draw 2s ease-in-out forwards;
}

@keyframes draw {
to {
stroke-dashoffset: 0;
}
}`

How it works: stroke-dasharray creates a dashed line. When the dash length equals the total path length, the line is solid. stroke-dashoffset slides that dash along the path. Start with the offset equal to the path length (the "dash" is shifted completely out of view), then animate it to 0. The line appears to draw itself.

Pro tip: You need the exact path length for this to work. Use path.getTotalLength() in your browser's DevTools console to find it, then set both stroke-dasharray and stroke-dashoffset to that value. Or just use a generously large value like 1000 — it works as long as both properties match.

Technique 2: CSS Transforms for Scaling and Rotation

SVG elements respond to transform just like HTML elements, but with one gotcha: the transform origin defaults to (0, 0) of the SVG viewBox, not the center of the element.

`.gear {
animation: spin 4s linear infinite;
transform-origin: center;
}

@keyframes spin {
to {
transform: rotate(360deg);
}
}`

For complex grouped SVGs, you may need to set transform-origin explicitly to the center of the group's bounding box. Use percentage values or specific pixel coordinates.

.gear-group { transform-origin: 120px 120px; }

Technique 3: Staggered Animations with animation-delay

Multiple elements animating at the same time looks mechanical. Add delays to create a cascade effect.

.logo-letter:nth-child(1) { animation-delay: 0s; } .logo-letter:nth-child(2) { animation-delay: 0.1s; } .logo-letter:nth-child(3) { animation-delay: 0.2s; } .logo-letter:nth-child(4) { animation-delay: 0.3s; } .logo-letter:nth-child(5) { animation-delay: 0.4s; }

Combine this with animation-fill-mode: backwards so elements stay invisible before their animation starts, and you get a polished reveal sequence with zero JavaScript.

Performance: CSS vs. JavaScript
For simple SVG animations (transforms, opacity, stroke-draw), CSS animations are faster than JavaScript libraries. Here's why:

CSS animations run on the compositor thread, not the main thread. JavaScript runs on the main thread. If your page is doing other work (network requests, layout calculations), JS animations hitch. CSS animations don't.
CSS animations have zero bundle cost. GreenSock is ~40KB minified. Anime.js is ~15KB. Even a few lines of custom JS requestAnimationFrame logic adds maintenance cost. CSS keyframes are free.
The GPU can accelerate CSS transform and opacity animations without involving the CPU. JS libraries can trigger GPU compositing, but they add overhead.
The one place JS wins: complex timeline sequencing, physics-based motion (springs, easing curves you can't express in CSS), and path morphing across multiple shapes. But for 90% of real-world SVG animation needs — loaders, hovers, draw-in effects, reveals — CSS is the better tool.

Real Scenario: A Loading Spinner and an Animated Logo
Loading Spinner (no JS, no images)

<svg viewBox="0 0 50 50" class="spinner"> <circle cx="25" cy="25" r="20" fill="none" stroke="#6366f1" stroke-width="4" /> </svg>

`.spinner circle {
stroke-dasharray: 126;
stroke-dashoffset: 126;
transform-origin: center;
animation: spin 1.2s linear infinite;
}

@keyframes spin {
to {
stroke-dashoffset: 0;
transform: rotate(360deg);
}
}`

One element, two properties, zero JS. Works in every modern browser.

Animated Logo Draw-In
A 5-letter wordmark where each letter draws in sequence:

`.wordmark path {
stroke-dasharray: 500;
stroke-dashoffset: 500;
animation: draw 0.8s ease-out forwards;
}

.wordmark path:nth-child(1) { animation-delay: 0s; }
.wordmark path:nth-child(2) { animation-delay: 0.15s; }
.wordmark path:nth-child(3) { animation-delay: 0.3s; }
.wordmark path:nth-child(4) { animation-delay: 0.45s; }
.wordmark path:nth-child(5) { animation-delay: 0.6s; }

@keyframes draw {
to { stroke-dashoffset: 0; }
}

The letters appear one after another, each drawing itself from left to right. Clean, performant, and entirely CSS-driven.

The Easy Way

You don't need to write all this CSS by hand for every project. I built an SVG animation playground where you can upload any SVG, experiment with draw-in, spin, fade, and stagger effects visually, and export the CSS code — no login, no uploads, no JavaScript.

I build lightweight browser-based tools at utilitylab.dev. If you want a free, no-login tool to animate SVGs with pure CSS and export the code, there's one at <https://utilitylab.dev/svg-animator>.

How to Split SRT Subtitle Files for TikTok, Shorts, and Course Clips

Robert Wallace — Mon, 06 Jul 2026 06:29:06 +0000

`You just finished recording a 90-minute podcast. It's gold — packed with quotable moments, sharp insights, funny tangents. You want to repurpose it into ten 60-second Shorts. You've got the video clips cut. Now you need the subtitles to match.

If you've ever tried to cut a long video into short clips and keep the subtitles aligned, you know exactly how painful this gets. The original SRT file covers the full 90 minutes. Each clip needs a separate SRT with remapped timestamps. Doing it by hand means opening the file, scanning through thousands of cue lines, copying the right block, and manually adjusting every timestamp.

There's a better way. Here's everything you need to know about splitting SRT files.

Why You Need to Split Subtitles

SRT splitting comes up more often than you'd think:

Long-form to short-form repurposing: A 2-hour podcast becomes 20 TikTok clips. Each clip needs its own subtitle file with timestamps starting at 00:00.
Course modules: A 60-minute lecture gets split into 10 six-minute lessons. Each module needs accurate subtitles.
Interview highlights: A recorded interview yields 5–8 highlight clips for social. You need captions that match each excerpt exactly.
Multi-platform delivery: Your video lives on YouTube with full captions, but the 15-second clips for Reels need separate subtitle files.

Without proper splitting, you end up with subtitles that say the wrong thing at the wrong time — or, worse, cues that reference times far outside the clip duration.

The Common Problems (And How to Fix Them)

Misaligned Timestamps

When you pull a segment from 00:12:34,567 to 00:13:20,891 and paste it into a new file without adjusting, the cues still reference the original timecodes. Your first subtitle might say 00:12:34,567 --> 00:12:36,000 — which means nothing in a 60-second clip that starts at 00:00.

Fix: Subtract the segment start time from every timestamp. If your clip starts at 00:12:34,567, every start_time and end_time in that block needs 00:12:34,567 subtracted.

Missing Cues

You copy what you think is the right range, but you accidentally skip a cue. The clip plays and a sentence has no subtitle for 3 seconds.

Fix: Always verify that your cue count matches. A 60-second clip of dialogue should have roughly 8–15 cues depending on speaking speed. If the count seems low, go back and check you didn't miss any.

Encoding Issues

SRT files are plain text, but they need to be UTF-8 encoded. If you edit an SRT in Notepad on Windows and save it as ANSI, special characters — accented letters, em dashes, smart quotes — turn into garbage.

Fix: Always save SRT files with UTF-8 encoding, no BOM. Most video editors will handle UTF-8 correctly. ANSI or UTF-16? Those cause silent failures.

Three Ways to Split an SRT File

1. By Time Range

This is the most common approach: define a start and end time, then extract every cue whose timestamp falls within that window. The tool remaps the start/end times so the first cue begins at 00:00:00,000.

Use this when you've already cut your video and know the exact timecodes for each clip.

2. By Cue Count

Set a number of cues per split (e.g., 20 cues per file). The tool cuts at cue boundaries automatically.

Use this when you're splitting a long subtitle file into equal-size chunks — great for chapter-based courses where each module should have roughly the same number of captions.

3. By Chapter Markers

Some subtitle files include chapter markers or scene changes. If your source material has clear breaks, you can split at those points.

Use this when your content is already organized into sections (like a conference talk with defined parts or an interview segmented by topic).

Real Scenario: A 2-Hour Conference Talk → 12 Instagram Reels

A client delivered a 2-hour conference keynote. They wanted 12 Reels — one per topic segment — each 45–90 seconds long.

The original SRT had 340 cues. Here's the workflow:

Mark the segments: Watch the video and note the timecodes for each topic. Segment 1: 00:00:00 to 00:08:15. Segment 2: 00:08:15 to 00:16:40. And so on.
Extract by time range: For each segment, pull all cues within the time window. The tool remaps timestamps so each clip's first cue starts at 00:00.
Verify cue alignment: Play each clip with its subtitle file. Check that the spoken words match the on-screen text. Pay extra attention at cut points — sometimes a sentence straddles two segments and the half-sentence in the next clip is confusing without context.
Export: Save each SRT with a matching filename. clip-01.srt, clip-02.srt, etc. Most editors auto-detect the subtitle file if it shares the video's base name.

The whole process took about 20 minutes — down from what would have been hours of manual timestamp editing.

The Easy Way

You can do this with a text editor and a spreadsheet. Or you can use a tool purpose-built for the job. I built an SRT splitter that does all of this in your browser — paste your SRT, choose your split method (by time, by cue count, or by chapter), and download the split files instantly. No login, no upload, no server processing.

I build lightweight browser-based tools at utilitylab.dev. If you want a free, no-login tool to split SRT subtitle files for TikTok, Shorts, or course clips, there's one at https://utilitylab.dev/srt-splitter.`

How to Calculate Title-Safe and Action-Safe Margins for Video

Robert Wallace — Mon, 06 Jul 2026 06:19:58 +0000

`You export a video, upload it to a platform, and — every time — text gets chopped at the edges. Maybe it's a lower-third title that looks centered in Premiere but gets clipped on YouTube. Maybe it's a call-to-action banner that's invisible on a TV broadcast. Or maybe you designed a beautiful motion graphics package only to find key elements falling off the sides on Instagram Reels.

The culprit? Safe zones — or more precisely, the lack of them.

If you're delivering video to any platform beyond your own laptop, you need to understand title-safe and action-safe margins. Here's what they are, why they matter, and how to calculate them for any format.

What Are Title-Safe and Action-Safe Areas?

Action-safe is the outer boundary. It typically sits at 90% of the frame (a 5% margin on each edge). Anything important happening visually — people, movement, scene composition — should stay within this area. Elements outside it risk being cropped by overscan on older TVs or by platform-specific cropping on social media.

Title-safe is the inner boundary. It sits at 80% of the frame (a 10% margin on each edge). Any text, logos, or critical UI elements belong here. This gives you a generous buffer even on aggressively cropped displays.

These aren't arbitrary numbers. They come from broadcast television standards (SMPTE RP 27.3 and ITU-R BT.1973), where CRT overscan could eat 5–10% of the visible picture. The standards carried over into digital production — and they're still relevant today because every platform crops differently.

Calculating Safe Zones for Any Aspect Ratio

The math is straightforward once you know your frame dimensions.

16:9 (1920 × 1080)

Zone	Margin	Pixel bounds
Full frame	0%	1920 × 1080
Action-safe	5%	1728 × 972 (centered)
Title-safe	10%	1536 × 864 (centered)

To calculate: subtract 2 × margin_percentage × dimension from each side. For a 10% margin on 1920px wide: 1920 - (2 × 0.10 × 1920) = 1536.

4:3 (1440 × 1080)

Zone	Margin	Pixel bounds
Full frame	0%	1440 × 1080
Action-safe	5%	1296 × 972
Title-safe	10%	1152 × 864

Vertical 9:16 (1080 × 1920) — for TikTok, Reels, Shorts

Zone	Margin	Pixel bounds
Full frame	0%	1080 × 1920
Action-safe	5%	972 × 1728
Title-safe	10%	864 × 1536

The same percentages work across ratios — just plug in your dimensions.

Why Platform Matters

Here's the messy reality: the 5%/10% rule is a guide, not a guarantee. Different platforms crop differently:

TV broadcast (NTSC/PAL): Overscan can eat 5–10%. Use strict 80/90% guides.
YouTube: Uses letterboxing/pillarboxing but doesn't overscan. Still, the YouTube player UI (progress bar, buttons) overlays on your video — keep text out of the bottom 8%.
Instagram Reels / TikTok: These platforms add their own UI chrome over your video. TikTok's caption bar, like button, and comment button overlap the bottom and right edges. Keep critical text inside the center 80%.
Digital signage: Custom aspect ratios (32:9 ultrawide, 2:1, even 1:1 if displayed on square screens). Always ask for the exact display resolution before designing.

Real Scenario: Delivering to Both Broadcast and Reels

A client needs motion graphics for a TV commercial and 9:16 Reels cutdowns from the same 1920 × 1080 master.

The master is framed with a 10% title-safe zone (1536 × 864). The logo bug sits in the bottom-right corner at x=1728, y=972 — inside action-safe but outside title-safe. That works for broadcast because the logo is visual, not text.

The Reels cutdown crops the center 1080 × 1920 region of the 1920 × 1080 master. The logo at 1728,972? Completely gone — it falls outside the 1080px width. Lesson: design text for the tightest format first. In this case, place all text inside a 864 × 1200 safe zone at the center — that survives both broadcast overscan and the Reels center crop.

The Easy Way

You can do this math by hand every time, or you can use a tool that does it for you. I built an interactive safe-zone calculator that works in your browser — no login required, no cloud processing. You pick your resolution and aspect ratio, and it draws the guides instantly on a preview canvas.

I build lightweight browser-based tools at utilitylab.dev. If you want a free, no-login tool to calculate title-safe and action-safe margins for any video format, there's one at https://utilitylab.dev/safe-zone-generator.`

How to Share Large Files Browser-to-Browser Without Upload Servers

Robert Wallace — Mon, 06 Jul 2026 06:08:21 +0000

`You need to send a 4 GB video file to a designer on the other side of the office. What do you do?

If you're like most people, you fire up WeTransfer, Dropbox, or Google Drive. You wait for the upload. They wait for the download. The file sits on someone else's server for 7 days, then it's gone. And if your file is over 2 GB, some of those services just say no.

There's a better way: send the file directly from your browser to theirs, with zero bytes touching a server.

How WebRTC File Transfers Actually Work

WebRTC (Web Real-Time Communication) is the same technology that powers video calls in Zoom, Google Meet, and Discord. But it also handles arbitrary data — including large files — through its RTCDataChannel API.

Here's the flow:

Signaling. Your browser creates an "offer" containing your connection capabilities (codecs, network details). This offer is sent to the recipient through a lightweight signaling server — typically just a WebSocket or a simple HTTP relay. The signaling server never sees the file data; it only exchanges connection metadata.
ICE negotiation. Both browsers exchange ICE (Interactive Connectivity Establishment) candidates. These are potential routes for the direct connection: same-network LAN, public IP via STUN, or relayed via TURN if both peers are behind strict NATs.
Direct peer connection. Once a route is found, the browsers connect directly. From this point forward, data flows peer-to-peer. The signaling server's job is done.
Data channel transfer. The file is chunked into small pieces (typically 16 KB each, respecting the SCTP MTU), transferred over the encrypted data channel, and reassembled on the receiving end. Progress is tracked in real time.

The entire transfer uses DTLS encryption — the same encryption layer that secures HTTPS. Nobody on the network can read the data in transit, and the signaling server never touches the payload.

Why No-Upload Is More Private

When you upload a file to WeTransfer or Dropbox, you're trusting that company with your data. Even with "encryption at rest," the company holds the keys. Their terms of service typically grant them broad rights to scan, analyze, or share your content for abuse prevention, legal compliance, or even product improvement.

With a direct browser-to-browser transfer:

The file never exists on any server (except the signaling metadata, which is discarded seconds after the connection is established)
The transfer is end-to-end encrypted by WebRTC's DTLS — no middleman can decrypt it
No account or login is required on either side
No copy lingers on a cloud provider's storage after the transfer completes

For sensitive assets — design mockups for an unreleased product, legal documents, internal financial reports — this is a meaningful privacy improvement over "upload to cloud and share a link."

When P2P File Sharing Works Best

Direct transfers shine in specific scenarios:

Same local network. Two people in the same office building can transfer files at LAN speeds (500 Mbps to 1 Gbps) instead of being bottlenecked by the building's internet uplink. A 5 GB file that takes 15 minutes over WeTransfer might take 30 seconds over the LAN.

Same-office asset handoff. Designers sending PSDs to developers, video editors passing RAW footage to colorists, engineers sharing log dumps — any scenario where both parties are online and need the file now.

Internal team tools. Instead of maintaining an internal file-drop server, teams can use a P2P transfer page that requires zero infrastructure. No S3 buckets, no file servers, no expiring-link cleanup scripts.

Practical Size Limits

The real limit isn't your internet connection — it's your browser's memory.

WebRTC data channels stream data in chunks, and the receiving browser needs to reassemble the file in memory. Chrome and Firefox can typically handle files up to 2 GB before memory pressure becomes noticeable. For larger files, look for a tool that uses the File System Access API to stream chunks directly to disk.

Network speed matters too. A 10 GB file over a symmetric gigabit connection takes about 80 seconds. Over a typical residential uplink (20 Mbps), that same file takes nearly 70 minutes — and both browsers need to stay open the whole time.

When NOT to Use P2P File Sharing

Direct transfers aren't the answer for everything. Skip them when:

Asynchronous transfers. The recipient needs to download the file tomorrow, but you want to send it now. P2P requires both parties to be online simultaneously. If the recipient closes their browser, the transfer fails. For async, you still need a server.

Mobile browsers. Mobile Safari and Chrome aggressively throttle background tabs and WebRTC data channels. A transfer that works fine on desktop may fail or stall on a phone, especially for files over 100 MB.

Strict corporate networks. Some enterprise firewalls block the UDP ports that WebRTC uses for ICE negotiation. The connection may fall back to a TURN relay, which re-introduces a server hop (and potential bandwidth limits).

Large groups. Sending a file to 50 people? P2P means 50 separate upload streams from your browser. A traditional upload-to-server-and-share model is far more efficient here.

The Bottom Line

Browser-to-browser file sharing isn't a replacement for cloud storage — it's a complement. For the specific case where both parties are online, the file is too large for WeTransfer's cap, or privacy matters more than convenience, P2P transfer is faster, more private, and simpler to set up than any server-based alternative.

I build lightweight browser-based tools at utilitylab.dev. If you want a free, no-login tool to share files directly browser-to-browser without uploading to a server, there's one at https://utilitylab.dev/p2p-file-share.`

How to Add JSON-LD Schema for AI Search Engines (OpenAI, Perplexity, Claude)

Robert Wallace — Mon, 06 Jul 2026 05:12:07 +0000

`You've got perfect meta descriptions, proper Open Graph tags, and a sitemap that Googlebot loves. So why does ChatGPT Search return outdated info about your app, and why does Perplexity hallucinate your pricing?

Because AI search engines don't parse the web the way Google does. They extract structured data into their reasoning context — and if your JSON-LD is missing, incomplete, or loosely typed, the AI fills gaps with whatever it thinks is correct. That's how "probably around $20/month" becomes a confident lie in a search result.

What JSON-LD Actually Does for AI

JSON-LD (JavaScript Object Notation for Linked Data) is a way to embed structured metadata in your HTML. Traditional search engines use it for rich snippets. AI search engines use it as factual grounding — they pull your schema into their context window instead of guessing from prose.

OpenAI Search, Perplexity, and Claude-powered search all read JSON-LD <script type="application/ld+json"> blocks. Get it right, and the AI cites your exact features, pricing, and availability. Get it wrong or miss it, and the AI infers whatever it can from body text — including your competitor's data.

The Schema Types That Matter for AI

Not all schema types are created equal. For AI extraction, these perform best:

SoftwareApplication

Perfect for SaaS tools and apps. Include name, applicationCategory, operatingSystem, offers (with price and priceCurrency), and featureList. AI models are trained to pull applicationCategory directly.

`json
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "MyTool",
"applicationCategory": "DeveloperApplication",
"operatingSystem": "Web",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
}
}

FAQPage

When users ask "Does X support Y?" in Perplexity, the answer often comes from FAQ schema. Each mainEntity with acceptedAnswer is a direct Q&A pair AIs extract verbatim.

Article

For blog posts and docs, use Article or TechArticle with datePublished, author, and headline. AI search engines prioritize schema dates over visible text when answering "is this current?"

WebApplication

If you offer a browser-based tool, this tells AI crawlers it's an interactive app (not just a landing page). Include browserRequirements and softwareVersion.

Common Mistakes That Break AI Extraction

Missing @id: Without a unique identifier, AI models can't distinguish your schema from similar ones on the page. Always add @id: "https://yoursite.com/#app".

Wrong @context URL: Some generators output "@context": "http://schema.org" instead of "https://schema.org". The https variant is the current standard — the http one works but is deprecated and some AI parsers treat it as reduced confidence.

Nested types without explicit roles: If your software is also a product, use additionalType rather than nesting blindly. Flat, explicit schemas parse more reliably than deeply nested ones.

Missing required properties: Each schema type has required fields. SoftwareApplication demands applicationCategory and operatingSystem. Omitting them means the schema block may be ignored entirely.

Validating Your Schema

Google's Rich Results Test is fine for traditional SEO, but it doesn't simulate AI extraction. For that, copy your JSON-LD into a validator that checks for: valid @context, all required properties, correct pricing format, and resolvable URLs in @id.

I build lightweight browser-based tools at utilitylab.dev. If you want a free, no-login tool to generate and validate JSON-LD schema optimized for AI search engines like OpenAI, Perplexity, and Claude, there's one at https://utilitylab.dev/ai-search-schema-generator.

How to Calculate DPI for Print Design (And Why 72 PPI Is the Wrong Default)

Robert Wallace — Tue, 30 Jun 2026 03:26:54 +0000

If you've ever designed something for print and had it come out blurry or the wrong size, the culprit is almost always one thing: wrong DPI assumptions.

Most designers start with the screen default — 72 or 96 pixels per inch — and treat it like a universal constant. It's not. That number only describes your monitor. Print, photo exports, and physical mockups have completely different requirements.

The basic math

DPI / PPI is just a ratio:

DPI = pixel count / physical size in inches

So if you have a 3000×4000 pixel image and you want to print it at 10×13.3 inches, the math is:

Width: 3000 / 10 = 300 DPI
Height: 4000 / 13.3 = 300 DPI

That's the sweet spot for most offset printing. Below 250 DPI and you'll start seeing softness on coated stock. Above 350 DPI is usually unnecessary and just bloats file size.

When 300 DPI isn't the answer

Billboards / large format: viewed from far away, 30–75 DPI is fine
Web / social: 72–150 PPI is plenty because screens are fixed-pixel devices
Retina / high-DPI screens: CSS reference pixel is 96, but the device may have 2× or 3× physical pixel density

The mistake is treating "print DPI" and "screen PPI" as the same number. They aren't.

Why designers get this wrong

Three common traps:

Resampling in Photoshop without checking actual dimensions — changing the DPI metadata doesn't add real detail.
Exporting at 72 PPI from Figma/Sketch — the artboard size in pixels is what matters, not the PPI label.
Ignoring bleed and trim — a standard US letter page with 0.125" bleed needs the file to be oversized before imposition.

The faster way to check

Instead of doing mental math, calculate the actual pixel density from the physical dimensions and native resolution. For a 27-inch 1440p monitor:

2560 / (27" × √(16/9)) ≈ 109 PPI

That tells you whether text will look sharp at arm's length — it's not a print spec, it's a viewing-distance spec.

A practical check before you export

Before sending a file to press or framing a photo:

Note the source pixel dimensions
Note the target physical size
Divide
Compare to the target medium's recommended density

If you're designing for multiple outputs — web, Instagram, and a 16×20 print — each needs its own crop/resample pass. One file rarely fits all destinations.

I build lightweight browser-based dev tools at utilitylab.dev. If you want a fast client-side DPI/PPI check without installing anything, there's one there.

How to Clean CSV Files Before Importing into Excel

Robert Wallace — Sun, 28 Jun 2026 09:41:33 +0000

Every analyst and developer has been here: you open a CSV export and the headers are a mess — extra spaces, inconsistent casing, random line breaks, and half the columns have names that won’t survive a database import.

Before you start cleaning in Excel, fix the source file. Excel will only make it worse.

Headers are the first thing I normalize. Trim whitespace, convert to lowercase or title case consistently, and replace spaces with underscores or hyphens. Consistent headers prevent JOIN failures, ambiguous column references, and broken analytics queries downstream.

Then remove empty rows and summarize rows. Exports from payment processors, ad platforms, and CRMs often sneak in totals or blank spacer rows. They look fine in a spreadsheet but break scripts and ETL pipelines the moment you automate the import.

Duplicate rows are another silent problem. They don’t always show up visually depending on the viewer, but they inflate metrics and corrupt aggregations. A quick deduplication pass on a stable key column — email, transaction ID, or timestamp + user ID — fixes this before it pollutes your dataset.

The last step is checking encoding. UTF-8 with BOM is the safest default. If your file opens with strange characters or column shifts, it’s almost always an encoding mismatch between the export tool and your target system.

If you’re doing this regularly, a browser-based cleaner that doesn’t upload the file is usually enough for one-off prep. It keeps the data local and avoids the friction of installing a preprocessing script for a single cleanup job.

How to Estimate GPT-4 API Costs Before Building

Robert Wallace — Sun, 28 Jun 2026 09:38:30 +0000

If you’re building an AI feature, the first thing to model is tokens — not model choice. Pricing pages show per-1K-token rates, but they don’t multiply the math for your actual prompt and completion patterns.

The mistake I see most often is estimating from a single “hello world” call. That number is almost always wrong because real usage has three cost layers: input tokens from system prompts, output tokens from model responses, and hidden costs from retries, logging, or repeated calls in loops.

Input cost is usually predictable if you count your system prompt and the average user message length. Output cost is where variance hides — it depends on max response length, temperature settings, and whether your app chains multiple model calls per interaction.

A practical approach before writing any production code: estimate prompt, completion, and training tokens separately. Run the pricing math at your expected daily call volume, then add a 2x buffer for traffic spikes and experimental prompts.

The trap nobody budgets for is long-running costs from prompt caching, context window growth, or feature expansion that quietly increases token counts. Modeling the ranges — minimum, expected, and worst case — before launch prevents the “why is my bill so high” moment later.

If you’re comparing providers or models, build the estimate table once and swap rates. The math is the same regardless of whether you’re using GPT-4, Claude, or another provider — only the per-1K-token numbers change.

How to Fix Messy Markdown from Notion or Obsidian

Robert Wallace — Sun, 28 Jun 2026 09:35:34 +0000

If you’ve ever exported from Notion or Obsidian, you know the pain: extra whitespace everywhere, empty links, inconsistent heading styles, and stray HTML that breaks your site or docs build.

The good news is the content is usually fine. It just needs normalization.

Headings are the first thing I fix. Exports often start with H2 or mix H1 and H2 depending on how the document was structured. Pick a single top-level heading style and normalize everything down to it. Tools that rewrite headings automatically save more time than manually editing each file.

Then I remove empty bullets and blank lines. They look harmless in an editor, but they show up as layout problems in static site generators and markdown linters. Stripping them out before import prevents a lot of downstream noise.

Links are the next cleanup step. Exported docs love to include anchors to nowhere — placeholders, internal cross-references, or empty hrefs. Removing those late is worth it because broken links are harder to spot once the content is staged.

Finally, code fences should have language tags. Obsidian usually preserves them; Notion often drops them. Adding them back makes the content readable in GitHub, dev.to, or any docs renderer.

If you’re pasting a doc into a markdown cleaner, the fastest workflow is: normalize headings, remove empty bullets, strip dead links, then verify the result in a renderer before using it in production.

Container Queries vs Media Queries: When to Use Which

Robert Wallace — Sun, 28 Jun 2026 08:24:44 +0000

I’ve been thinking about this lately: media queries handle page-level layout changes fine, but they fall apart when the same component needs to behave differently depending on where it sits in the DOM.

That’s where container queries change the equation.

Media queries respond to the viewport. Container queries respond to the component’s container size. This matters for reusable design systems: a card component might sit in a 200px sidebar in one place and an 800px grid in another. With media queries alone, you’d need extra classes, wrapper changes, or JavaScript to handle that. Container queries let the component adapt based on its own context.

The practical rule I use: keep media queries for the page shell and major layout tiers. Use container queries inside reusable components that appear in multiple contexts. This keeps the CSS predictable without duplicating component variants.

A few real-world constraints worth knowing:
- Browser support is solid in modern browsers, but older versions still need fallbacks
- Container queries can’t replace media queries for user preferences like prefers-color-scheme or prefers-reduced-motion
- The syntax (cqw, cqh, container-type) takes a few minutes to internalize

If you’re experimenting with container query syntax, it helps to generate query blocks and paste them directly into your components instead of hand-writing each one. Testing a few variations is faster than guessing values in the editor.

DEV Community: Robert Wallace

How to Animate SVG Without JavaScript (Pure CSS Animation)

The Foundation: SVG and CSS Working Together

Technique 1: Draw-In Effects with stroke-dasharray and stroke-dashoffset

Technique 2: CSS Transforms for Scaling and Rotation

Technique 3: Staggered Animations with animation-delay

The Easy Way

How to Split SRT Subtitle Files for TikTok, Shorts, and Course Clips

Why You Need to Split Subtitles

The Common Problems (And How to Fix Them)

Misaligned Timestamps

Missing Cues

Encoding Issues

Three Ways to Split an SRT File

1. By Time Range

2. By Cue Count

3. By Chapter Markers

Real Scenario: A 2-Hour Conference Talk → 12 Instagram Reels

The Easy Way

How to Calculate Title-Safe and Action-Safe Margins for Video

What Are Title-Safe and Action-Safe Areas?

Calculating Safe Zones for Any Aspect Ratio

16:9 (1920 × 1080)

4:3 (1440 × 1080)

Vertical 9:16 (1080 × 1920) — for TikTok, Reels, Shorts

Why Platform Matters

Real Scenario: Delivering to Both Broadcast and Reels

The Easy Way

How to Share Large Files Browser-to-Browser Without Upload Servers

How WebRTC File Transfers Actually Work

Why No-Upload Is More Private

When P2P File Sharing Works Best

Practical Size Limits

When NOT to Use P2P File Sharing

The Bottom Line

How to Add JSON-LD Schema for AI Search Engines (OpenAI, Perplexity, Claude)

What JSON-LD Actually Does for AI

The Schema Types That Matter for AI

SoftwareApplication

FAQPage

Article

WebApplication

Common Mistakes That Break AI Extraction

Validating Your Schema

How to Calculate DPI for Print Design (And Why 72 PPI Is the Wrong Default)

The basic math

When 300 DPI isn't the answer

Why designers get this wrong

The faster way to check

A practical check before you export

How to Clean CSV Files Before Importing into Excel

How to Estimate GPT-4 API Costs Before Building

How to Fix Messy Markdown from Notion or Obsidian

Container Queries vs Media Queries: When to Use Which

Technique 1: Draw-In Effects with `stroke-dasharray` and `stroke-dashoffset`