How to check if used paginate in laravel
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# How to Check if Pagination Was Used in Laravel: A Deep Dive
As developers working with Laravel, one of the most common scenarios we encounter is conditional rendering based on whether a specific piece of data was retrieved using pagination. You might have some methods that return simple collections and others that return paginated results, and you need different UI elements displayed accordingly. The challenge lies in reliably determining this state within your Blade views.
The common attempt, as you noted, checking `$products->links()`, often fails or behaves unpredictably because it depends entirely on the specific object returned by the Eloquent method, which isn't always a straightforward boolean indicator of whether pagination was *applied* upstream.
This post will explore why that simple check fails and provide robust, developer-focused methods for correctly determining if pagination was utilized in your data retrieval process.
---
## The Pitfall of Simple Property Checks
When you call `->paginate(10)`, the result is an instance of a `LengthAwarePaginator` (or similar class), which *does* have a `links()` method. However, if you are working with a plain Eloquent collection that hasn't been paginated, or if the data retrieval pathway has been altered, accessing properties directly can lead to errors or false negatives.
Your attempt:
```blade
@if($products->links())
{{$products->links()}}
@endif
```
This often fails because `$products` might be a standard `Illuminate\Database\Eloquent\Collection` rather than a Paginator object, leading to an error when calling methods that don't exist on the collection itself in that specific context.
## The Developerâs Solution: Checking the Data Type and Context
The most reliable way to solve this is not to rely solely on method calls on the data itself, but rather to track the state *at the point where the data is passed* to the viewâwhich is typically within your Controller logic.
### Method 1: Passing a Flag from the Controller (Recommended)
The cleanest and most explicit way to manage this state is to perform the check in your controller and pass a boolean flag to the view. This keeps the presentation logic separate from the data retrieval logic, adhering to good separation of concerns.
**In your Controller:**
```php
use Illuminate\Http\Request;
use App\Models\Product;
class ProductController extends Controller
{
public function index(Request $request)
{
// Check if pagination is explicitly requested (e.g., via a query parameter)
$paginate = $request->input('paginate', false);
if ($paginate) {
// Pagination used
$products = Product::paginate(15);
} else {
// Simple collection used
$products = Product::all();
}
return view('products.index', compact('products', 'paginationUsed'));
}
}
```
**In your Blade View:**
Now, the check becomes trivial and reliable:
```blade
@if($paginationUsed)
{{ $products->links() }}
@endif
{{-- Display the products --}}
@foreach ($products as $product)
{{ $product->name }}
@endforeach
```
This approach is highly recommended because it clearly communicates *why* the pagination links are being shown, making your code easier to maintain and debug. This pattern aligns perfectly with how robust applications should be structured when dealing with complex data flows, much like the principles discussed on [Laravel Company](https://laravelcompany.com).
### Method 2: Checking for the Paginator Instance Directly
If you absolutely must check the object itself within the view (though less ideal), you can check if the object implements the `Paginator` interface or has the specific properties of a paginator.
```blade
{{-- Check if the object has the links method, which implies it's a Paginator --}}
@if (method_exists($products, 'links'))
{{ $products->links() }}
@endif
```
While this works in many cases, relying on `method_exists` is less idiomatic than passing explicit state flags.
## Conclusion
When dealing with conditional rendering based on data retrieval methods like Eloquent's `paginate()`, avoid trying to infer the state solely from method calls within the view layer. Instead, treat the controller as the gatekeeper for data context. By explicitly setting a boolean flag in your controller and passing it to the view, you ensure that your presentation layer is reacting to intentional state changes rather than fragile object properties. This results in cleaner, more predictable, and more maintainable Laravel applications.