Mert

The MD5 vs SHA-256 debate has been mostly settled in security circles for years — but that doesn’t stop the question from coming up constantly in real projects. Developers reach for MD5 out of habit, encounter it in legacy codebases, or genuinely wonder whether it’s “good enough” for a non-security use case. This guide gives you a clear technical comparison, explains why MD5 is broken for security purposes, and maps out exactly when each algorithm — or a stronger alternative — belongs in your stack.

How MD5 Works

MD5 (Message-Digest Algorithm 5) was designed by Ron Rivest in 1991. It processes input in 512-bit blocks and produces a fixed 128-bit (16-byte) hash, typically displayed as a 32-character hex string.

// Node.js
const crypto = require('crypto');

const md5 = crypto.createHash('md5').update('hello').digest('hex');
console.log(md5); // '5d41402abc4b2a76b9719d911017c592'

The algorithm runs four rounds of bitwise operations over each block, mixing the data through 64 transformation steps. It was designed for speed, and it achieves it — MD5 can hash several gigabytes per second on modern hardware.

How SHA-256 Works

SHA-256 is a member of the SHA-2 family, standardised by NIST in 2001. It produces a 256-bit (32-byte) digest — displayed as a 64-character hex string — and processes input in 512-bit blocks through 64 rounds of compression using a mix of bitwise operations, modular additions, and logical functions drawn from the first 64 prime numbers.

// Node.js
const sha256 = crypto.createHash('sha256').update('hello').digest('hex');
console.log(sha256);
// '2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824'

The longer digest and more complex round function make SHA-256 significantly harder to reverse or find collisions in.

Security Comparison: Why MD5 Is Broken

MD5 is cryptographically broken in two fundamental ways:

Collision Attacks

A collision is when two different inputs produce the same hash output. In 2004, researchers demonstrated practical MD5 collisions. By 2008, researchers had created a rogue Certificate Authority certificate by exploiting MD5 collisions in SSL certificates. Today, generating an MD5 collision takes seconds on consumer hardware using tools like HashClash.

// These two different inputs produce the same MD5 hash
// (real example from the 2004 Wang et al. paper — truncated for illustration)
// Input A: d131dd02c5e6eec4...
// Input B: d131dd02c5e6eec5...
// Both hash to: 79054025255fb1a26e4bc422aef54eb4

Preimage and Second-Preimage Resistance

While full preimage attacks on MD5 aren’t yet practical for arbitrary inputs, theoretical weaknesses have been demonstrated, and the small 128-bit output space means brute-force attacks are increasingly feasible with GPU clusters. Rainbow tables covering huge portions of common MD5 hashes exist publicly and can crack unsalted passwords in milliseconds.

SHA-256 Security Posture

As of 2026, no practical collision attacks against SHA-256 exist. NIST continues to recommend SHA-256 as a general-purpose cryptographic hash. SHA-256 provides 128 bits of collision resistance (birthday bound) and 256 bits of preimage resistance — both well beyond current computational capabilities.

Performance: MD5’s One Real Advantage

MD5 is genuinely faster than SHA-256. Approximate throughput on a modern x86-64 CPU using hardware-optimised implementations:

• MD5: ~600–800 MB/s
• SHA-256: ~300–450 MB/s (software); up to ~3,000 MB/s with Intel SHA Extensions
• SHA-512: ~400–600 MB/s on 64-bit systems

On modern hardware with SHA-NI instructions (available on most x86-64 processors since ~2017), SHA-256 speed is competitive with MD5. The performance gap that once justified MD5 in non-security contexts has largely closed.

When MD5 Is Still Acceptable

MD5 remains appropriate in a narrow set of non-security scenarios:

• Non-security checksums — detecting accidental data corruption during file transfers where an adversary is not present. Many torrent clients and package mirrors still provide MD5 checksums for convenience. If integrity against tampering matters, use SHA-256.
• Hash-based caching keys — generating a short, fast cache key from a large string or object where collisions would only cause a cache miss, not a security breach.
• Deduplication identifiers in internal systems — identifying duplicate files or database records in a closed, trusted environment where an attacker cannot craft inputs.
• Legacy system compatibility — interoperating with older APIs or protocols that require MD5 and cannot be changed.

The key test: could an adversary benefit from a collision or preimage attack here? If yes, MD5 is off the table.

When to Use SHA-256 (or Stronger)

• Password storage — neither MD5 nor SHA-256 alone. Use bcrypt, Argon2, or scrypt, which are intentionally slow and incorporate salting. SHA-256 without a work factor is still crackable with GPU rainbow tables.
• Digital signatures and certificates — SHA-256 is the current standard for TLS certificates, code-signing, and document signatures. SHA-1 was deprecated; SHA-256 minimum is required.
• HMAC authentication — HMAC-SHA256 for API request signing and message authentication codes.
• Content integrity (public-facing) — npm’s package integrity fields use SHA-512; Docker image digests use SHA-256.
• File integrity where tampering is a concern — software downloads, firmware updates, build artifacts.

// HMAC-SHA256 for API signing
const hmac = crypto.createHmac('sha256', process.env.SECRET_KEY);
hmac.update(requestBody);
const signature = hmac.digest('hex');

SHA-256 vs SHA-512: A Quick Note

SHA-512 produces a 512-bit digest and offers more security margin, but SHA-256 is sufficient for nearly all current applications. SHA-512 is faster than SHA-256 on 64-bit platforms due to its wider internal word size, making it a reasonable choice for hashing large files. Both are considered secure in 2026.

Generate and Compare Hashes

Use the DevPlaybook Hash Generator to compute MD5, SHA-256, SHA-512, and other digests side by side. It’s useful for verifying file checksums, testing HMAC signatures, and understanding how digest length varies across algorithms.

Want these tools available offline? The DevToolkit Bundle ($9 on Gumroad) packages 40+ developer tools into a single downloadable kit — no internet required.

Conclusion

In the MD5 vs SHA-256 comparison, the answer is unambiguous for security work: always use SHA-256 (or stronger). MD5’s collision vulnerabilities make it unsuitable for anything where an adversary could exploit a hash match. Reserve MD5 strictly for legacy compatibility and non-security checksums where performance is paramount and adversarial manipulation is impossible. When in doubt, SHA-256 is the safe default — and with SHA-NI hardware acceleration, the performance penalty is minimal.

Free Developer Tools

If you found this article helpful, check out DevToolkit — 40+ free browser-based developer tools with no signup required.

Popular tools: JSON Formatter · Regex Tester · JWT Decoder · Base64 Encoder

🛒 Get the DevToolkit Starter Kit on Gumroad — source code, deployment guide, and customization templates.

Monorepos — single Git repositories containing multiple projects or packages — have become the default architecture at companies like Google, Meta, and Microsoft. In the JavaScript ecosystem, the rise of monorepos has spawned a competitive tooling landscape: Nx, Turborepo, and Lerna are the three most prominent options, each taking a different philosophy to solving the same core problem: making large codebases fast and maintainable.

This guide compares all three in depth — their architecture, caching strategies, task orchestration, ecosystem integrations, and the scenarios where each shines.

Why Monorepos? The Problem They Solve

Before comparing tools, it’s worth understanding what problem they solve. A monorepo containing 20 packages has 20 sets of dependencies, 20 build pipelines, and 20 test suites. Without tooling, npm install in the root, then building every package in sequence, would take 30+ minutes on any non-trivial codebase.

Monorepo tools solve this with three mechanisms:

• Dependency graph analysis: Understand which packages depend on which, so changes are only propagated where needed
• Intelligent task scheduling: Run independent tasks in parallel, dependent tasks in sequence
• Caching: Skip tasks whose inputs haven’t changed — build once, reuse everywhere

Lerna: The Pioneer

Lerna was the first major JavaScript monorepo tool, released in 2015. It pioneered the concept of managing multiple npm packages in a single repository and automating versioning and publishing. For years, “monorepo” and “Lerna” were nearly synonymous in the JS community.

How Lerna Works

Lerna works on top of a package manager’s workspace protocol (npm workspaces, yarn workspaces, or pnpm workspaces). It provides two key capabilities:

• Task running: Run scripts across all packages, with change detection to skip unchanged ones
• Publishing: Version bumping (fixed or independent versioning) and npm publish automation across all packages

# lerna.json
{
  "version": "independent",
  "npmClient": "pnpm",
  "useWorkspaces": true,
  "packages": ["packages/*", "apps/*"],
  "command": {
    "publish": {
      "conventionalCommits": true,
      "message": "chore(release): publish"
    }
  }
}

# Run build across all changed packages
npx lerna run build --since origin/main

# Publish all changed packages
npx lerna publish --conventional-commits

Lerna + Nx Power Mode

In 2022, Nrwl (the company behind Nx) took over Lerna’s maintenance and integrated Nx’s task runner as Lerna’s default engine. Modern Lerna (v6+) uses Nx under the hood for caching and task orchestration, meaning you get Lerna’s publishing automation with Nx’s performance.

# lerna.json — enable Nx integration
{
  "version": "independent",
  "useWorkspaces": true,
  "$schema": "node_modules/lerna/schemas/lerna-schema.json",
  "useNx": true,  // Enable Nx task runner
  "npmClient": "npm"
}

When to Use Lerna

Lerna’s sweet spot is open-source libraries that publish multiple packages to npm. If your primary concern is versioning coordination and publishing automation across packages (e.g., a component library shipping 20 independent packages), Lerna’s conventional commits integration and changelog generation are best-in-class. For pure task running and caching, Turborepo or Nx are stronger.

Turborepo: Speed-First Simplicity

Turborepo was built by Jared Palmer and acquired by Vercel in 2021. Its philosophy is radical simplicity: a minimal configuration file, zero opinions about your project structure, and an obsessive focus on making builds fast through caching.

How Turborepo Works

Turborepo reads your turbo.json to understand task dependencies and caching rules, then orchestrates task execution with maximum parallelism:

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],  // ^ means "all dependencies' build first"
      "inputs": ["src/**", "package.json", "tsconfig.json"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "inputs": ["src/**", "tests/**"],
      "outputs": []
    },
    "lint": {
      "inputs": ["src/**", ".eslintrc*"],
      "outputs": []
    },
    "dev": {
      "persistent": true,
      "cache": false  // Never cache dev servers
    }
  }
}

With this config, turbo build will:

• Build all packages in dependency order (topological sort)
• Parallelize independent packages
• Skip packages whose inputs (files) haven’t changed (hash-based cache)
• On cache hit: restore outputs from cache without re-running (milliseconds vs minutes)

Remote Caching with Vercel

Turborepo’s killer feature is remote caching — sharing the build cache across your entire team and CI/CD pipeline. When developer A builds @acme/ui, the result is pushed to Vercel’s remote cache. When developer B runs the same build with identical inputs, they get a cache hit and skip the build entirely.

# Link to Vercel remote cache
npx turbo login
npx turbo link

# Now every turbo run is potentially a cache hit from any team member's build
turbo build

# Output:
# @acme/ui:build: cache hit, replaying output...
# @acme/utils:build: cache hit, replaying output...
# @acme/web:build: >>> FULL TURBO  (all dependencies were cached)
# Tasks: 12 successful, 12 total
# Cached: 12 cached, 12 total
# Time: 847ms >>> FULL TURBO

You can also self-host the remote cache using open-source alternatives like ducktape-cache or turborepo-remote-cache.

Turborepo Codebase Structure

my-monorepo/
├── apps/
│   ├── web/          # Next.js app
│   └── docs/         # Docusaurus site
├── packages/
│   ├── ui/           # Shared React components
│   ├── config/       # Shared configs (eslint, tsconfig)
│   └── utils/        # Shared utilities
├── turbo.json
└── package.json      # Workspace root with workspaces field

When to Use Turborepo

Turborepo is ideal for application-focused monorepos where speed and simplicity are the priorities. If you’re building a suite of Next.js apps with shared packages and want to set up a monorepo in 30 minutes with excellent Vercel deployment integration, Turborepo is the natural choice. Its minimal configuration surface means less to learn and maintain.

Nx: The Full-Featured Platform

Nx, developed by Nrwl, is the most feature-rich of the three tools. It goes well beyond task running to provide a full development platform: code generation, project graph visualization, automated migrations, and first-class integrations for React, Angular, Node.js, Next.js, and dozens of other frameworks.

How Nx Works

Nx builds a project graph by analyzing your source code — not just package.json imports, but actual TypeScript/JavaScript import statements. This means it understands dependencies even in non-npm-linked scenarios:

# nx.json
{
  "$schema": "./node_modules/nx/schemas/nx-schema.json",
  "namedInputs": {
    "default": ["{projectRoot}/**/*", "sharedGlobals"],
    "production": [
      "default",
      "!{projectRoot}/**/*.spec.ts",
      "!{projectRoot}/jest.config.ts"
    ]
  },
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"],
      "cache": true
    },
    "test": {
      "inputs": ["default", "^production", "{workspaceRoot}/jest.preset.js"],
      "cache": true
    }
  }
}

The Project Graph

Run npx nx graph to open an interactive visualization of your entire monorepo’s dependency graph. This is invaluable for understanding impact of changes:

# Show what's affected by changes since main branch
npx nx affected:graph

# Run only tests for affected projects
npx nx affected --target=test --base=main

# Run specific project's build
npx nx build my-app

# Run with task runner parallelism
npx nx run-many --target=build --all --parallel=4

Nx Generators (Code Generation)

Nx’s code generators (formerly called “schematics”) are one of its most powerful differentiators. They automate creating consistent new apps, libraries, and components:

# Add a new React app to the monorepo
npx nx g @nx/react:app my-new-app

# Add a shared library
npx nx g @nx/react:lib ui-components --directory=shared

# Add a component to a library
npx nx g @nx/react:component Button --project=shared-ui-components

# Generate a Node.js API
npx nx g @nx/node:app my-api --framework=express

Each generator creates files, updates imports, and registers the project in the workspace — ensuring consistent structure across your entire codebase without manual copy-pasting.

Nx Cloud: Remote Caching and Distributed Task Execution

Nx Cloud (the paid cloud offering) provides remote caching similar to Turborepo, plus Distributed Task Execution (DTE) — a unique feature that distributes CI tasks across multiple agents in parallel:

// In CI: distribute 50 test suites across 10 agents
npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js"
npx nx affected --target=test
npx nx-cloud stop-all-agents

This can reduce a 30-minute CI run to 5 minutes by running tasks on 6 parallel agents. The free tier of Nx Cloud covers most small-to-medium teams.

When to Use Nx

Nx is best for large enterprise monorepos, teams that want strong conventions enforced by tooling, and mixed-technology workspaces (e.g., Angular frontends + Node.js backends + shared TypeScript libraries). Its generator ecosystem and migration tools (“Nx migrate”) make upgrading framework versions (React 18 → 19, Next.js 14 → 15) much less painful.

Head-to-Head Comparison

Configuration Complexity

• Turborepo: Minimal — one turbo.json with task definitions. New developers are productive in an hour.
• Lerna: Minimal for publishing workflows, moderate for task orchestration.
• Nx: High initial learning curve, but the investment pays off at scale. Deep configuration options for fine-grained control.

Caching

• Turborepo: Excellent. Hash-based local + remote caching (Vercel or self-hosted). Dead simple to configure.
• Lerna: Delegates to Nx when useNx: true. Standalone Lerna has basic task hashing.
• Nx: Excellent. Sophisticated input/output tracking, remote caching via Nx Cloud, distributed execution.

Ecosystem and Framework Support

• Turborepo: Framework-agnostic. Works with any build system. No code generation.
• Lerna: Framework-agnostic. Publishing-focused.
• Nx: Deep integrations for React, Angular, Vue, Next.js, Nest.js, Express, Fastify, Storybook, Cypress, Jest, Vite, and more.

Scalability

• Turborepo: Scales well to hundreds of packages. Simpler mental model may become a limitation at Google/Meta scale.
• Lerna: Scales to hundreds of packages for publishing; leans on Nx for performance at scale.
• Nx: Battle-tested at thousands of packages. Distributed task execution handles the most extreme CI scenarios.

Migration Considerations

If you’re converting an existing multi-repo setup to a monorepo, or migrating between tools:

• To Turborepo: Add turbo.json, define task pipeline, run turbo build. Usually done in an afternoon.
• To Nx: Run npx nx@latest init in an existing monorepo — Nx’s init command auto-detects projects and generates configuration. Full migration can take days for large repos.
• To Lerna: npx lerna init in a workspace root. Primary migration concern is configuring your versioning/publishing strategy.

Decision Guide

Choose Turborepo if:

• You want to get started quickly with minimal configuration
• You’re deploying primarily to Vercel and want native integration
• Your team is small to medium and prefers simplicity over features
• You have application packages rather than published libraries

Choose Nx if:

• You have a large team with diverse technology stacks
• You want enforced conventions and code generation
• CI times are a serious bottleneck and you need distributed execution
• You’re building on Angular, or a mix of Angular + React + Node

Choose Lerna if:

• You’re building an open-source library that publishes multiple npm packages
• Conventional commits + automated changelog generation is a priority
• You want Lerna’s publishing workflow with Nx’s performance under the hood

Conclusion

The monorepo tooling ecosystem has matured rapidly. Turborepo wins on simplicity and developer experience for application monorepos. Nx wins on features, scalability, and enterprise-grade tooling. Lerna wins specifically for publishing-focused open-source library repositories.

Notably, these tools aren’t mutually exclusive — modern Lerna uses Nx internally, and you can run Turborepo alongside other tools. The most important choice is picking one and using it consistently across your team.

For more on JavaScript tooling decisions, see our comparisons of npm vs pnpm vs yarn and Vite vs Webpack.

Free Developer Tools

If you found this article helpful, check out DevToolkit — 40+ free browser-based developer tools with no signup required.

Popular tools: JSON Formatter · Regex Tester · JWT Decoder · Base64 Encoder

🛒 Get the DevToolkit Starter Kit on Gumroad — source code, deployment guide, and customization templates.