Fixing PHP Fatal error: Uncaught TypeError: Argument 1 passed to processData() must be of type int, string given (PHP 8 Type Hint Mismatch)

intermediate๐Ÿ˜ PHP2026-03-26| This error typically occurs in environments running PHP 8.0 or newer. It can happen on any operating system (Linux, Windows, macOS) with popular web servers like Apache, Nginx, or Caddy, and PHP-FPM or similar SAPI.

Error Message

Fatal error: Uncaught TypeError: Argument 1 passed to processData() must be of type int, string given, called in /var/www/html/app.php on line 42
#php#type-error#type-hint#php8#strict-types

TL;DR: Quick Fix

This TypeError indicates your PHP code is trying to pass a string to a function that explicitly expects an int (or another scalar type like bool or float).

To resolve this, you generally have two main approaches:

  • Coerce the input data: Ensure the variable you're passing is of the expected type. For instance, cast a string to an integer using (int)$myString before calling the function. This is often the most straightforward and correct solution.
  • Adjust the function's type hint: If the function was always intended to accept a string, update its type declaration. Change int to string in the function signature.

Quickly identify the problematic line (e.g., /var/www/html/app.php on line 42) and the function (processData()). Then, apply one of the fixes described above to resolve the immediate issue.

The Incident: Uncaught TypeError in PHP 8

Imagine it's 2 AM, and a critical service unexpectedly crashes. You check the logs and discover an alarming message:

Fatal error: Uncaught TypeError: Argument 1 passed to processData() must be of type int, string given, called in /var/www/html/app.php on line 42

This isn't a memory leak or a missing file error. Instead, it's a TypeError, specifically highlighting a mismatch. The error indicates that the data type provided for a function argument doesn't match the expected type. PHP 8, by default, enforces stricter scalar type checks than previous versions, making these types of errors more prevalent if your codebase isn't fully type-safe.

Reproducing the Error

Let's look at a simple code example that would trigger this very error:

<?php

declare(strict_types=1); // Not strictly required for THIS error in PHP 8 (due to lossy conversion), but it emphasizes strictness.

function processData(int $data): string
{
    return "Processed: " . ($data * 2);
}

$userInput = "123abc"; // This is a string, but we want to process it as a number.

// This line will cause the TypeError
echo processData($userInput); // app.php on line 42

?>

When this script executes, PHP examines the type hint for $data within the processData() function. It expects an int, but it receives a string (specifically, "123abc"). Since PHP 8 is stricter about type conversions that would result in data loss, it immediately throws a TypeError and halts script execution.

Root Cause Analysis

At its core, this problem stems from violating a function's defined contract. In PHP 7, scalar type hints were often loosely enforced unless you explicitly used declare(strict_types=1);. PHP 8 introduced a significant change.

Starting with PHP 8, scalar type declarations are more strictly enforced. This applies by default for internal functions, and for user-defined functions when the value cannot be coerced without data loss (like converting a non-numeric string to an integer). If the calling scope also has declare(strict_types=1); enabled, then all type mismatches, even lossless ones, will throw a TypeError.

Let's break down the error message:

  • Fatal error: Uncaught TypeError: The script stopped abruptly because of a type mismatch.
  • Argument 1 passed to processData(): The issue lies with the first argument supplied to the processData function.
  • must be of type int, string given: The function expects an integer, but it received a string instead.
  • called in /var/www/html/app.php on line 42: This pinpoints the exact file and line number where the problematic function call occurred.

In essence, your processData function is declared with an int $data type hint, signaling to PHP that the value passed to $data must be an integer. However, your code on line 42 attempts to pass a string ("123abc") to this parameter, resulting in the fatal error.

Resolution Strategies

You have several options to resolve this TypeError, and the best choice depends on the intended behavior of your code.

1. Coerce the Input Data (Most Common & Recommended)

If processData() is genuinely designed to work only with integers, then your primary goal should be to ensure it receives an int. This scenario frequently arises when handling user input, parsing API responses, or processing data from external sources that might deliver numeric values as strings.

Example Fix: Casting to int

<?php

declare(strict_types=1);

function processData(int $data): string
{
    return "Processed: " . ($data * 2);
}

$userInput = "123abc"; // Still a string

// Option A: Explicit cast to int. "123abc" becomes 123.
$processedInput = (int)$userInput;
echo processData($processedInput) . "\n";

// Option B: Using intval(). Similar effect, also converts to 123.
// echo processData(intval($userInput)) . "\n";

// Option C: If you expect a strictly numeric string and want to validate it
if (is_numeric($userInput)) {
    echo processData((int)$userInput) . "\n";
} else {
    echo "Error: Invalid numeric input provided. Expected a number, got '$userInput'." . "\n";
}

?>

Explanation: The (int) cast attempts to convert the string to an integer. For a string like "123abc", it will convert to 123, discarding any non-numeric characters after the initial numbers. If the string contains no leading numeric characters (e.g., "hello world"), it will convert to 0. Always be mindful of this conversion behavior and validate user input thoroughly if data integrity is crucial.

2. Adjust the Function's Type Hint (If the Hint was Incorrect)

Perhaps your processData() function was always meant to handle strings, or even a mix of data types. In such cases, the existing type hint is simply wrong and needs correction.

Example Fix: Changing int to string

<?php

declare(strict_types=1);

// The function now correctly expects a string
function processData(string $data): string
{
    // You'll now need to handle the string data appropriately within the function.
    // This might involve validation or conversion if numeric processing is still needed.
    if (is_numeric($data)) {
        return "Processed numeric string: " . ((int)$data * 2) . "\n";
    } else {
        return "Processed non-numeric string: " . $data . "\n";
    }
}

$userInput = "123abc";
echo processData($userInput);

$anotherInput = "hello world";
echo processData($anotherInput);

?>

Explanation: This strategy modifies the function's contract to accurately reflect the data it's designed to receive. This is the ideal fix if the original type hint was a mistake, or if the requirements for the function have evolved.

3. Allow for Multiple Types (PHP 8 Union Types)

If your function genuinely needs to accept more than one scalar type โ€“ for instance, it can gracefully handle either an int or a string โ€“ PHP 8's Union Types offer a clean and expressive solution.

Example Fix: Using Union Types (int|string)

<?php

declare(strict_types=1);

// The function now accepts either an int or a string
function processData(int|string $data): string
{
    if (is_int($data)) {
        return "Processed int: " . ($data * 2) . "\n";
    } elseif (is_string($data)) {
        // Handle string data, potentially converting if it's numeric
        if (is_numeric($data)) {
            return "Processed numeric string: " . ((int)$data * 2) . "\n";
        } else {
            return "Processed non-numeric string: " . $data . "\n";
        }
    }
    // This line should ideally not be reached with a well-defined union type hint.
    return "Invalid input type encountered." . "\n"; 
}

$userInputString = "123abc";
echo processData($userInputString);

$userInputInt = 456;
echo processData($userInputInt);

?>

Explanation: The int|string declaration informs PHP that either an int or a string is an acceptable argument. Inside the function, you would then use conditional checks like is_int(), is_string(), or instanceof to determine the actual type and process it accordingly.

4. Allow Null (Nullable Types)

In scenarios where the argument might sometimes be omitted or explicitly passed as null, you can make the type hint nullable. This is useful for optional parameters.

Example Fix: Using Nullable Type (?int)

<?php

declare(strict_types=1);

// The function can accept an int or null
function processData(?int $data): string
{
    if ($data === null) {
        return "No data provided.\n";
    }
    return "Processed: " . ($data * 2) . "\n";
}

$userInput = null;
echo processData($userInput);

$validInput = 123;
echo processData($validInput);

// This will always cause a TypeError, as "123abc" is neither an int nor null,
// and cannot be losslessly coerced to an int even without strict_types=1.
// echo processData("123abc"); 

?>

Explanation: The ? prefix before the type (e.g., ?int) allows the argument to be either the declared type (an int in this case) or null. This provides flexibility for optional data.

Verification Steps

Once you've applied one of the recommended fixes, follow these steps to ensure everything is working correctly:

  • Clear PHP Opcache: If your environment uses an opcache (like OPcache), make sure it's cleared. Alternatively, restart your PHP-FPM service or web server (e.g., sudo systemctl restart php8.2-fpm) to load the updated code.
  • Run the script: Execute your app.php script again. If it's part of a web application, refresh the relevant page in your browser.
  • Check for errors: Confirm that the Fatal error: Uncaught TypeError message no longer appears. Check your web server error logs (e.g., Apache error log, Nginx error log) and PHP-FPM logs.
  • Verify output: Finally, ensure that your application behaves as expected. Confirm that it produces the correct output or performs the intended actions without introducing any new errors.

Further Reading

Related Error Notes