Fix for Issue with Public Folder Structure

To address the error in the terminal related to the 'public' folder being exposed at the root level, ensure that you do not need to specify the public folder explicitly.

Instead of using: src="/public/logoicon/logoOrange.png"

Try using: src="/logoicon/logoOrange.png"

If you are still facing a 400 bad request error, consider the following steps:

- Verify URL string syntax

- Check for corrupted cache and cookies

- Ensure the image size is not too large

- Look out for any whitespaces in folder names

Recently, I delved into learning Next.js and encountered a perplexing issue with my images not appearing on the page. Despite experimenting with different formats and diligently checking the source, it turns out that the images were actually stored in the public folder.

The resolution to my image dilemma:

By placing the images in the directory below:

public/images/[insert image file]

This was the root cause of my problem. Hopefully, this insight proves beneficial to someone else facing a similar issue.

To simplify your image path in NEXT.JS, you can easily remove the "/public" part before your image name. This is because the public folder is already exposed and automatically scanned by NEXT.JS for assets.

For example, if your image is located at /public/test.jpg, simply change it to /test.jpg

Consider using "/" in place of "/public" for improved efficiency

<Image src={`/image.png`} alt="something" height={150} width={200}/>

Ever since Next13's Image changes, the only effective setup seems to be something like this. Interestingly, they have chosen to ditch the objectFit props in favor of using styles instead - although the reasoning behind this decision is a bit unclear!

Regardless, I hope this explanation proves helpful for some of you. Remember, you don't have to name it 'imageAsset' like in the example - feel free to use whatever name you prefer as long as it's in your public folder!

I decided to provide a detailed example because I understand that some individuals visiting here may be new to Next/React and might not grasp the implementation completely yet.

IMPORTANT: Simply removing /public/ from the image src or import won't work in all scenarios, especially if your images are not directly within the public folder - similar to how my images are stored in a subfolder within that directory. Therefore, eliminating /public/ will not yield the desired results.

import Image from "next/image"
import imageAsset from '/public/images/your-image-asset.webp'

export default function Component() {
  return (
    <>
      <Image src={imageAsset} width={1920} height={1080} style={{objectFit: 'cover', objectPosition: 'center'}} />
    </>
  )
}

If you encounter this issue while utilizing nextjs 13, the solution is to import the image as an object from the public folder. Here's an example:

import placeholderImage from '../../../../../public/placeholder.jpg';

To use it in the Image component, follow this format:

<Image
  width={120}
  height={60}
  src={placeholderImage}
  alt="brand"
 />

You can also apply styles – for instance, if you wish to set a background image in a div, you can achieve it like so:

<div style={{ backgroundImage: `url(${placeholderImage.src})`}}>

 </div>

If you're utilizing middleware, the issue lies within the [matcher] where you must provide parameters for it to ignore.

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - api (API routes)
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     */
    '/((?!api|_next/static|_next/image|favicon.ico).*)',
  ],
}

_next/static|_next/image -> by excluding these, it avoids errors and returns a 404 [text/plain]

Learn more about Next.js routing middleware here.

My experience involved encountering another application running on port 3000. To identify the conflicting process, I executed the command below in my Mac Terminal.

$ lsof -i :3000

Subsequently, I terminated the process using Activity Monitor. In this scenario, it turned out to be an additional instance of NodeJS occupying port 3000.

Successfully bringing in the image by using

import img from '/public/[insert your image here]'

Here's a solution that worked for me: First, move all your images to the public/(assets or images) folder. Then, import these images into an index.js file like so:

import imageName from './imageName.gif'
import imageName from './imageName.jpg'
import imageName from './imageName.png'

export{
    imageName, imageName, imageName
}

Next, import the necessary image from the projects/assets/index.js file like this:

import { imageName } from '../public/assets'

Finally, use the image in your code like this:

<Image src={imageName} />

Encountered this issue earlier today. It appears to be related to a malfunction in next/dynamic causing the image not to load correctly. Though it may not be the most ethical approach, manually importing your component without the image seems to have resolved the issue for me.

I recently encountered this issue, most likely due to a modification in the basePath setting within next.config.js.

You can resolve this by resetting the basePath to its default value (basePath: '',)

After exploring various suggestions from different sources, I experimented with different solutions to no avail. Eventually, I decided to switch from using the Next.js Image tag to the HTML img tag. I made a tweak by eliminating the public directory and directly including the path /image.png, and surprisingly it dynamically worked upon loading.

I uploaded my image to the public directory and then implemented the following code successfully:

<Image src={'/abc.png'} alt="/" width='125' height='50' />

Encountered a similar issue during production build while attempting to upload an image via an input field, despite smooth operation in development mode. Upon investigation, I discovered that the public folder becomes unreachable during production builds. To access the newly uploaded images, consider utilizing services such as Amazon S3. Hopefully, this solution proves useful to others facing the same challenge.