via.placeholder.com Migration Guide (Service Changes)

History

Via.placeholder.com service reliability and deprecation

Via.placeholder.com has gone through multiple ownership and maintenance changes. The service has experienced extended downtime, rate limiting, and changes in behavior for requests without referer headers. Developers who relied on it in production faced broken images in demos, documentation, and staging environments.

The core problem is that via.placeholder.com was always intended as a simple developer utility, not a production-grade service. It was not built for CDN caching, has no SLA, and does not provide the modern routes that production placeholder use cases require.

If you are finding via.placeholder.com URLs in your codebase during a dependency audit, that is a signal to migrate before the service changes behavior again.

URL format

Understanding the via.placeholder.com URL structure

Via.placeholder.com uses a path-based format: /WIDTHxHEIGHT for basic dimensions, /WIDTHxHEIGHT/BGCOLOR for custom background, and a text query parameter for labels. Colors are hex without the # prefix. The path format is similar to fallback.pics with minor differences in path ordering.

The main difference: via.placeholder.com puts the dimensions in the first path segment without a prefix, while fallback.pics uses /api/v1/ as the base prefix. Text and color parameters match closely.

# via.placeholder.com format
https://via.placeholder.com/400x300
https://via.placeholder.com/400x300/7C3AED
https://via.placeholder.com/400x300/7C3AED/FFFFFF
https://via.placeholder.com/400x300?text=Hello+World
https://via.placeholder.com/400        # square shorthand

# fallback.pics equivalents
https://fallback.pics/api/v1/400x300
https://fallback.pics/api/v1/400x300/7C3AED
https://fallback.pics/api/v1/400x300/7C3AED/FFFFFF
https://fallback.pics/api/v1/400x300?text=Hello+World
https://fallback.pics/api/v1/square/400

Bulk migration

Finding and replacing via.placeholder.com URLs at scale

Use ripgrep to find all via.placeholder.com occurrences across your project. The URL appears in HTML templates, JSX files, CSS background properties, JSON fixtures, and Markdown documentation. Search without file type filters first to get a complete count.

A regex substitution handles the path prefix difference. The dimensions segment stays the same; only the domain and base path change. Test the substitution on a single file before running it across the full codebase.

# Find all occurrences
rg "via\.placeholder\.com" --include="*.{ts,tsx,js,jsx,html,md,json}"

# Preview the replacement (dry run with sed)
rg -l "via\.placeholder\.com" |   xargs sed 's|https://via\.placeholder\.com/\([0-9x]*\)|https://fallback.pics/api/v1/\1|g'

# Apply in place (macOS)
rg -l "via\.placeholder\.com" |   xargs sed -i '' 's|https://via.placeholder.com/|https://fallback.pics/api/v1/|g'

# Apply in place (Linux)
rg -l "via\.placeholder\.com" |   xargs sed -i 's|https://via.placeholder.com/|https://fallback.pics/api/v1/|g'

Edge cases

Handling via.placeholder.com edge cases in the migration

The square shorthand (/400 instead of /400x400) does not have a direct equivalent in fallback.pics. Replace these with either /400x400 or /square/400—both produce a square image. The /square/ route is more explicit and readable.

Via.placeholder.com supports a /gif route for animated GIFs. If you are using GIF placeholders, migrate to the animated skeleton route instead. The skeleton animation is lighter than a GIF and has better visual quality.

Text with special characters in via.placeholder.com URLs uses %20 for spaces. Fallback.pics also accepts %20 but the + encoding is shorter. Either works; leave the encoding as-is during migration to avoid double-encoding issues.

Storybook

Updating Storybook args and fixtures

Storybook stories often define image URLs in args defaults, argTypes controls, or directly in story JSX. Search your .stories.tsx and .stories.js files separately since they may use different patterns than application code.

Component README files and docs pages that show via.placeholder.com URLs in example code also need updating. These are documentation issues but they matter because they are often the reference that future developers copy from when adding new image slots.

// Before migration – Storybook args
export const Default = {
  args: {
    imageUrl: 'https://via.placeholder.com/400x300',
    avatarUrl: 'https://via.placeholder.com/80x80',
  },
};

// After migration
export const Default = {
  args: {
    imageUrl: 'https://fallback.pics/api/v1/400x300',
    avatarUrl: 'https://fallback.pics/api/v1/avatar/80',
  },
};

Prevention

Preventing via.placeholder.com from reappearing after migration

Add a CI check that scans the source tree for via.placeholder.com and fails the build if found. This prevents new occurrences from sneaking in through copy-pasted code, imported dependencies, or contributors unfamiliar with the migration.

Update your team's development setup guide or onboarding document to reference fallback.pics instead of via.placeholder.com. Most developers reach for a placeholder service by memory or convention; the first reference they see in internal docs is usually the one they copy.

# package.json – add to lint or test scripts
# "lint:placeholders": "! rg via.placeholder.com src/ docs/"

# .github/workflows/ci.yml – add a step
- name: Check for deprecated placeholder URLs
  run: |
    if rg "via\.placeholder\.com" src/ docs/ --quiet; then
      echo "Found via.placeholder.com URLs. Please migrate to fallback.pics."
      exit 1
    fi

Resources

Related placeholder migration and comparison guides

Related posts cover fakeimg.pl migration and a comparison of URL-based placeholder APIs.

https://fallback.pics/docs/
https://fallback.pics/placeholder-image-api/
https://fallback.pics/blog/fakeimg-alternatives-production/
https://fallback.pics/blog/placeholder-com-alternative/