Image path

Hi all,

I have a markdown document with an image such as:

![This is an image](image.png)

Where can I tell hugo that images live in directory static/img and that they will be in directory img of the resulting website? I searched documentation and forum for this information but found it nowhere.

1 Like

You don’t tell Hugo that; this is how it works by default.

You can put images in both /static and /content (the last is useful if you want to keep content (md) and media files together).

If you’re using an img sub-directory within the static directory, just include it in your markdown image tag:

![This is an image](/img/image.png)

Anything in static gets converted to a sub-directory of the baseURL on building the site. So the image will end up at

Thanks for your answers. I put images in the same directory than the article and everything is fine (it even works in Github’s preview which is cool).

Nevertheless, putting images in the article directory is not a good solution because when you render article in the article list, image src won’t be correct. I think that there should be an option to indicate where is the image directory.


@casa: I think that there should be an option to indicate where is the image directory

I’m sure you could do that by editing your img.html [and figure.html ] in /layouts/shortcodes/ to hard-wire the path to wherever you wanted to keep your images into the src="..." part of the HTML they generate.

But it seems a bit a bit of a palaver to me, when you can just add your image directory under /static/ and then reference that easily enough as /name-of-imagedir/ in your image tags [as I outlined above].

I’m working on adding a github (and probably bitbucket) compatible mode, and this will need to manage to figure out relative linking for images and also ‘get it right’ for the article list case that @casa mentions.


its a work in progress - I’m in the middle of a stack of new things right now, so progress is lumpy :slight_smile:


I’m afraid that implementing this solution result in documents that are not markdown anymore. What if I want to generate PDF or ePub from my articles? This is not just hypothetical, this is what I do with each article on my website, at Project for this site is at

Can you explain what you mean by ‘not markdown’? My focus is to enable hugo to be compatible with the markdown used in GitHub - as our devs and users seem to read both the hugo site, and the GitHub version of the same documents.

And so to me, having Hugo able to deal with GitHub markdown paths is improving its markdown compatibility.

1 Like

Sorry, I was not replying to your post but to the previous one that suggested to use shortcodes, which are not makdown.

Regarding your post, I totally agree that there should be a compatibility with github links. Nevertheless, I think that the issue is more general : a markdown document should not define image paths because they depend on the rendering context. Image paths in github and website or while rendering PDF for instance will be different.

Thus I think that there should be a way to tell Hugo the path for images and it would set it correctly for various document locations.

I have fixed this issue using pandoc with a filter that sets the path of the image while processing.

1 Like

The above answers are helpful, but I found that when using a baseURL that is not the root of the website I had to also add canonifyURLs: true to the config.yml

Then the markdown ![](/images/pic.jpg)
worked to reference image content from static/images/pic.jpg


Specially on same host multilingual sites with different base URLs depending upon the language, setting canonifyURLs in config file is a MUST if you want to get the same results both in development mode (i.e. using hugo server) and in production mode (using the published directory tree).

Just curious. You mention this in a very old thread.
Is this a tip you you did not find stated in the documentation?

I read the current documentation and I was frustrated after not finding more hints for setting up my multilingual site. My case is a single-host but different url base upon language (i.e. “http://myhost/en” for English and “http://myhost/fr” for French). In my case, when relative links worked using hugo’s server, then they didn’t work using the generated site. And viceversa, when I managed to make them work in the generated site, they didn’t work using hugo’s server. By setting canonical paths all links where generated fine in both environments.